File command not accepting wild card characters












0














On my Linux machine, I can use the file command to list the contents of a directory by using it this way:



file /home/user/*


It prints the file type for each file in the /home/user/ directory. This way, I can get to know the list of all the files in that directory.



However, on a remote Linux machine, I am not able to use the wild card character with file command.



file /home/user/*
/home/user/*: cannot open `/home/user/*' (No such file or directory)


Does file command not support wild card characters on certain versions of Linux? Or is this is a restriction?



Thanks.










share|improve this question






















  • What shell are you using on the remote? Run echo $0
    – Attie
    Dec 11 '18 at 15:32












  • Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
    – AFH
    Dec 11 '18 at 15:40










  • It is running bash shell.
    – Neon Flash
    Dec 11 '18 at 16:34










  • Yes, I can use the ls command as well. However, in this specific case I need to use file command.
    – Neon Flash
    Dec 11 '18 at 16:35






  • 1




    @NeonFlash was my answer helpful?
    – Attie
    Dec 11 '18 at 21:55
















0














On my Linux machine, I can use the file command to list the contents of a directory by using it this way:



file /home/user/*


It prints the file type for each file in the /home/user/ directory. This way, I can get to know the list of all the files in that directory.



However, on a remote Linux machine, I am not able to use the wild card character with file command.



file /home/user/*
/home/user/*: cannot open `/home/user/*' (No such file or directory)


Does file command not support wild card characters on certain versions of Linux? Or is this is a restriction?



Thanks.










share|improve this question






















  • What shell are you using on the remote? Run echo $0
    – Attie
    Dec 11 '18 at 15:32












  • Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
    – AFH
    Dec 11 '18 at 15:40










  • It is running bash shell.
    – Neon Flash
    Dec 11 '18 at 16:34










  • Yes, I can use the ls command as well. However, in this specific case I need to use file command.
    – Neon Flash
    Dec 11 '18 at 16:35






  • 1




    @NeonFlash was my answer helpful?
    – Attie
    Dec 11 '18 at 21:55














0












0








0







On my Linux machine, I can use the file command to list the contents of a directory by using it this way:



file /home/user/*


It prints the file type for each file in the /home/user/ directory. This way, I can get to know the list of all the files in that directory.



However, on a remote Linux machine, I am not able to use the wild card character with file command.



file /home/user/*
/home/user/*: cannot open `/home/user/*' (No such file or directory)


Does file command not support wild card characters on certain versions of Linux? Or is this is a restriction?



Thanks.










share|improve this question













On my Linux machine, I can use the file command to list the contents of a directory by using it this way:



file /home/user/*


It prints the file type for each file in the /home/user/ directory. This way, I can get to know the list of all the files in that directory.



However, on a remote Linux machine, I am not able to use the wild card character with file command.



file /home/user/*
/home/user/*: cannot open `/home/user/*' (No such file or directory)


Does file command not support wild card characters on certain versions of Linux? Or is this is a restriction?



Thanks.







linux






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 11 '18 at 15:27









Neon Flash

1306




1306












  • What shell are you using on the remote? Run echo $0
    – Attie
    Dec 11 '18 at 15:32












  • Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
    – AFH
    Dec 11 '18 at 15:40










  • It is running bash shell.
    – Neon Flash
    Dec 11 '18 at 16:34










  • Yes, I can use the ls command as well. However, in this specific case I need to use file command.
    – Neon Flash
    Dec 11 '18 at 16:35






  • 1




    @NeonFlash was my answer helpful?
    – Attie
    Dec 11 '18 at 21:55


















  • What shell are you using on the remote? Run echo $0
    – Attie
    Dec 11 '18 at 15:32












  • Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
    – AFH
    Dec 11 '18 at 15:40










  • It is running bash shell.
    – Neon Flash
    Dec 11 '18 at 16:34










  • Yes, I can use the ls command as well. However, in this specific case I need to use file command.
    – Neon Flash
    Dec 11 '18 at 16:35






  • 1




    @NeonFlash was my answer helpful?
    – Attie
    Dec 11 '18 at 21:55
















What shell are you using on the remote? Run echo $0
– Attie
Dec 11 '18 at 15:32






What shell are you using on the remote? Run echo $0
– Attie
Dec 11 '18 at 15:32














Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
– AFH
Dec 11 '18 at 15:40




Note that ls /home/user/ will show the files in a directory without using a wildcard. You can add -l for more information, though not of course what file shows.
– AFH
Dec 11 '18 at 15:40












It is running bash shell.
– Neon Flash
Dec 11 '18 at 16:34




It is running bash shell.
– Neon Flash
Dec 11 '18 at 16:34












Yes, I can use the ls command as well. However, in this specific case I need to use file command.
– Neon Flash
Dec 11 '18 at 16:35




Yes, I can use the ls command as well. However, in this specific case I need to use file command.
– Neon Flash
Dec 11 '18 at 16:35




1




1




@NeonFlash was my answer helpful?
– Attie
Dec 11 '18 at 21:55




@NeonFlash was my answer helpful?
– Attie
Dec 11 '18 at 21:55










1 Answer
1






active

oldest

votes


















4














The file utility doesn't handle wildcards, the shell does...



The shell is likely bash or dash or sh, or something similar - you can run echo $0 at a prompt to see what's running.





As mentioned above, the wildcards are handled by the shell (not the application), and the expansion's default behaviour might be a little unexpected. Bash, for example, will use the following behaviour:




  • If /home/user either doesn't exist, or has nothing in it, then /home/user/* will not expand, but will remain as-is (i.e: /home/user/*).

  • If /home/user is a directory with two files a and b in it, then /home/user/* will expand to /home/user/a /home/user/b.


With bash, you can:




  • Disable "globbing" entirely by running set -f, or

  • Expand a "glob" to nothing if it doesn't match anything by running shopt -s nullglob.




This means that either:




  • The remote shell doesn't support globbing at all

  • The remote shell has globbing disabled by default (try running set +f to enable it)




If your end goal really is to "run find on all entities in /home/user/", then you could try the following:



find /home/user/ -maxdepth 1 -type f -print0 
| xargs -0 file




  • -maxdepth 1 prevents recursion


  • -type f shows only files (not directories, symlinks, etc...)


  • find's -print0 and xargs' -0 arguments are used together to use a NUL character () to separate entries, as special characters line newline (n) are valid in filenames.


  • xargs will use records provided via stdin, and use them as additional parameters to the specified command (file in this case)




Default (set +f / shopt -u nullglob)



$ tree
.
└── x

1 directory, 0 files
$ echo glob x/*
glob x/*


$ touch x/a x/b
$ tree
.
└── x
├── a
└── b
$ echo glob x/*
glob x/a x/b


No Globbing (set -f / shopt -u nullglob)



$ tree
.
└── x

1 directory, 0 files
$ echo glob x/*
glob x/*


$ touch x/a x/b
$ tree
.
└── x
├── a
└── b
$ echo glob x/*
glob x/*


Null Glob Expansion (set +f / shopt -s nullglob)



$ tree
.
└── x

1 directory, 0 files
$ echo glob x/*
glob


$ touch x/a x/b
$ tree
.
└── x
├── a
└── b
$ echo glob x/*
glob x/a x/b





share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1382669%2ffile-command-not-accepting-wild-card-characters%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4














    The file utility doesn't handle wildcards, the shell does...



    The shell is likely bash or dash or sh, or something similar - you can run echo $0 at a prompt to see what's running.





    As mentioned above, the wildcards are handled by the shell (not the application), and the expansion's default behaviour might be a little unexpected. Bash, for example, will use the following behaviour:




    • If /home/user either doesn't exist, or has nothing in it, then /home/user/* will not expand, but will remain as-is (i.e: /home/user/*).

    • If /home/user is a directory with two files a and b in it, then /home/user/* will expand to /home/user/a /home/user/b.


    With bash, you can:




    • Disable "globbing" entirely by running set -f, or

    • Expand a "glob" to nothing if it doesn't match anything by running shopt -s nullglob.




    This means that either:




    • The remote shell doesn't support globbing at all

    • The remote shell has globbing disabled by default (try running set +f to enable it)




    If your end goal really is to "run find on all entities in /home/user/", then you could try the following:



    find /home/user/ -maxdepth 1 -type f -print0 
    | xargs -0 file




    • -maxdepth 1 prevents recursion


    • -type f shows only files (not directories, symlinks, etc...)


    • find's -print0 and xargs' -0 arguments are used together to use a NUL character () to separate entries, as special characters line newline (n) are valid in filenames.


    • xargs will use records provided via stdin, and use them as additional parameters to the specified command (file in this case)




    Default (set +f / shopt -u nullglob)



    $ tree
    .
    └── x

    1 directory, 0 files
    $ echo glob x/*
    glob x/*


    $ touch x/a x/b
    $ tree
    .
    └── x
    ├── a
    └── b
    $ echo glob x/*
    glob x/a x/b


    No Globbing (set -f / shopt -u nullglob)



    $ tree
    .
    └── x

    1 directory, 0 files
    $ echo glob x/*
    glob x/*


    $ touch x/a x/b
    $ tree
    .
    └── x
    ├── a
    └── b
    $ echo glob x/*
    glob x/*


    Null Glob Expansion (set +f / shopt -s nullglob)



    $ tree
    .
    └── x

    1 directory, 0 files
    $ echo glob x/*
    glob


    $ touch x/a x/b
    $ tree
    .
    └── x
    ├── a
    └── b
    $ echo glob x/*
    glob x/a x/b





    share|improve this answer




























      4














      The file utility doesn't handle wildcards, the shell does...



      The shell is likely bash or dash or sh, or something similar - you can run echo $0 at a prompt to see what's running.





      As mentioned above, the wildcards are handled by the shell (not the application), and the expansion's default behaviour might be a little unexpected. Bash, for example, will use the following behaviour:




      • If /home/user either doesn't exist, or has nothing in it, then /home/user/* will not expand, but will remain as-is (i.e: /home/user/*).

      • If /home/user is a directory with two files a and b in it, then /home/user/* will expand to /home/user/a /home/user/b.


      With bash, you can:




      • Disable "globbing" entirely by running set -f, or

      • Expand a "glob" to nothing if it doesn't match anything by running shopt -s nullglob.




      This means that either:




      • The remote shell doesn't support globbing at all

      • The remote shell has globbing disabled by default (try running set +f to enable it)




      If your end goal really is to "run find on all entities in /home/user/", then you could try the following:



      find /home/user/ -maxdepth 1 -type f -print0 
      | xargs -0 file




      • -maxdepth 1 prevents recursion


      • -type f shows only files (not directories, symlinks, etc...)


      • find's -print0 and xargs' -0 arguments are used together to use a NUL character () to separate entries, as special characters line newline (n) are valid in filenames.


      • xargs will use records provided via stdin, and use them as additional parameters to the specified command (file in this case)




      Default (set +f / shopt -u nullglob)



      $ tree
      .
      └── x

      1 directory, 0 files
      $ echo glob x/*
      glob x/*


      $ touch x/a x/b
      $ tree
      .
      └── x
      ├── a
      └── b
      $ echo glob x/*
      glob x/a x/b


      No Globbing (set -f / shopt -u nullglob)



      $ tree
      .
      └── x

      1 directory, 0 files
      $ echo glob x/*
      glob x/*


      $ touch x/a x/b
      $ tree
      .
      └── x
      ├── a
      └── b
      $ echo glob x/*
      glob x/*


      Null Glob Expansion (set +f / shopt -s nullglob)



      $ tree
      .
      └── x

      1 directory, 0 files
      $ echo glob x/*
      glob


      $ touch x/a x/b
      $ tree
      .
      └── x
      ├── a
      └── b
      $ echo glob x/*
      glob x/a x/b





      share|improve this answer


























        4












        4








        4






        The file utility doesn't handle wildcards, the shell does...



        The shell is likely bash or dash or sh, or something similar - you can run echo $0 at a prompt to see what's running.





        As mentioned above, the wildcards are handled by the shell (not the application), and the expansion's default behaviour might be a little unexpected. Bash, for example, will use the following behaviour:




        • If /home/user either doesn't exist, or has nothing in it, then /home/user/* will not expand, but will remain as-is (i.e: /home/user/*).

        • If /home/user is a directory with two files a and b in it, then /home/user/* will expand to /home/user/a /home/user/b.


        With bash, you can:




        • Disable "globbing" entirely by running set -f, or

        • Expand a "glob" to nothing if it doesn't match anything by running shopt -s nullglob.




        This means that either:




        • The remote shell doesn't support globbing at all

        • The remote shell has globbing disabled by default (try running set +f to enable it)




        If your end goal really is to "run find on all entities in /home/user/", then you could try the following:



        find /home/user/ -maxdepth 1 -type f -print0 
        | xargs -0 file




        • -maxdepth 1 prevents recursion


        • -type f shows only files (not directories, symlinks, etc...)


        • find's -print0 and xargs' -0 arguments are used together to use a NUL character () to separate entries, as special characters line newline (n) are valid in filenames.


        • xargs will use records provided via stdin, and use them as additional parameters to the specified command (file in this case)




        Default (set +f / shopt -u nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob x/*


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/a x/b


        No Globbing (set -f / shopt -u nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob x/*


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/*


        Null Glob Expansion (set +f / shopt -s nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/a x/b





        share|improve this answer














        The file utility doesn't handle wildcards, the shell does...



        The shell is likely bash or dash or sh, or something similar - you can run echo $0 at a prompt to see what's running.





        As mentioned above, the wildcards are handled by the shell (not the application), and the expansion's default behaviour might be a little unexpected. Bash, for example, will use the following behaviour:




        • If /home/user either doesn't exist, or has nothing in it, then /home/user/* will not expand, but will remain as-is (i.e: /home/user/*).

        • If /home/user is a directory with two files a and b in it, then /home/user/* will expand to /home/user/a /home/user/b.


        With bash, you can:




        • Disable "globbing" entirely by running set -f, or

        • Expand a "glob" to nothing if it doesn't match anything by running shopt -s nullglob.




        This means that either:




        • The remote shell doesn't support globbing at all

        • The remote shell has globbing disabled by default (try running set +f to enable it)




        If your end goal really is to "run find on all entities in /home/user/", then you could try the following:



        find /home/user/ -maxdepth 1 -type f -print0 
        | xargs -0 file




        • -maxdepth 1 prevents recursion


        • -type f shows only files (not directories, symlinks, etc...)


        • find's -print0 and xargs' -0 arguments are used together to use a NUL character () to separate entries, as special characters line newline (n) are valid in filenames.


        • xargs will use records provided via stdin, and use them as additional parameters to the specified command (file in this case)




        Default (set +f / shopt -u nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob x/*


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/a x/b


        No Globbing (set -f / shopt -u nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob x/*


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/*


        Null Glob Expansion (set +f / shopt -s nullglob)



        $ tree
        .
        └── x

        1 directory, 0 files
        $ echo glob x/*
        glob


        $ touch x/a x/b
        $ tree
        .
        └── x
        ├── a
        └── b
        $ echo glob x/*
        glob x/a x/b






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 11 '18 at 15:49

























        answered Dec 11 '18 at 15:34









        Attie

        10.9k32444




        10.9k32444






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1382669%2ffile-command-not-accepting-wild-card-characters%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Plaza Victoria

            Puebla de Zaragoza

            Musa