#!/usr/bin/env foo #!vs /usr/bin/foo [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite













This question already has an answer here:



  • Why is it better to use “#!/usr/bin/env NAME” instead of “#!/path/to/NAME” as my shebang?

    9 answers



Which of the above forms is "better" for running bash, python etc. scripts? Why can't I just do #!$(which foo)? Is it neccecery to specify full path to env? I gather from this answer, that the path /usr/bin/env is set in stone for all *nix-es, much more than /usr/bin/python3 for example. Is that so?




scripting path shebang




share|improve this question














marked as duplicate by muru, Hunter.S.Thompson, peterh, jimmij, Raphael Ahrens Nov 19 '17 at 15:01


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


















    up vote
    0
    down vote

    favorite













    This question already has an answer here:



    • Why is it better to use “#!/usr/bin/env NAME” instead of “#!/path/to/NAME” as my shebang?

      9 answers



    Which of the above forms is "better" for running bash, python etc. scripts? Why can't I just do #!$(which foo)? Is it neccecery to specify full path to env? I gather from this answer, that the path /usr/bin/env is set in stone for all *nix-es, much more than /usr/bin/python3 for example. Is that so?




    scripting path shebang




    share|improve this question














    marked as duplicate by muru, Hunter.S.Thompson, peterh, jimmij, Raphael Ahrens Nov 19 '17 at 15:01


    This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite












      This question already has an answer here:



      • Why is it better to use “#!/usr/bin/env NAME” instead of “#!/path/to/NAME” as my shebang?

        9 answers



      Which of the above forms is "better" for running bash, python etc. scripts? Why can't I just do #!$(which foo)? Is it neccecery to specify full path to env? I gather from this answer, that the path /usr/bin/env is set in stone for all *nix-es, much more than /usr/bin/python3 for example. Is that so?




      scripting path shebang




      share|improve this question















      This question already has an answer here:



      • Why is it better to use “#!/usr/bin/env NAME” instead of “#!/path/to/NAME” as my shebang?

        9 answers



      Which of the above forms is "better" for running bash, python etc. scripts? Why can't I just do #!$(which foo)? Is it neccecery to specify full path to env? I gather from this answer, that the path /usr/bin/env is set in stone for all *nix-es, much more than /usr/bin/python3 for example. Is that so?





      This question already has an answer here:



      • Why is it better to use “#!/usr/bin/env NAME” instead of “#!/path/to/NAME” as my shebang?

        9 answers





      scripting path shebang





      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 19 '17 at 11:00









      Jeff Schaller

      32.1k849109




      32.1k849109










      asked Nov 19 '17 at 10:49









      Vorac

      94621732




      94621732




      marked as duplicate by muru, Hunter.S.Thompson, peterh, jimmij, Raphael Ahrens Nov 19 '17 at 15:01


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






      marked as duplicate by muru, Hunter.S.Thompson, peterh, jimmij, Raphael Ahrens Nov 19 '17 at 15:01


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          You can’t just write #!$(which foo) because that line is interpreted by the kernel, which does not understand complex syntaxes like $().



          The kernel does not search for the command in the PATH environment variable. That’s why you have to specify the full path to the command.



          The use of /usr/bin/env is a clever hack used to search the command in the PATH. Even if there is a /usr/bin/python3 program, you may for example have installed a more recent version of Python in a different path, for example in you home directory.






          share|improve this answer




















          • Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
            – Vorac
            Nov 19 '17 at 11:03










          • Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
            – user2233709
            Nov 19 '17 at 11:13










          • You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
            – David Favor
            Nov 19 '17 at 13:01










          • @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
            – user2233709
            Nov 19 '17 at 13:08










          • @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
            – user2233709
            Nov 19 '17 at 14:23

















          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote













          You can’t just write #!$(which foo) because that line is interpreted by the kernel, which does not understand complex syntaxes like $().



          The kernel does not search for the command in the PATH environment variable. That’s why you have to specify the full path to the command.



          The use of /usr/bin/env is a clever hack used to search the command in the PATH. Even if there is a /usr/bin/python3 program, you may for example have installed a more recent version of Python in a different path, for example in you home directory.






          share|improve this answer




















          • Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
            – Vorac
            Nov 19 '17 at 11:03










          • Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
            – user2233709
            Nov 19 '17 at 11:13










          • You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
            – David Favor
            Nov 19 '17 at 13:01










          • @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
            – user2233709
            Nov 19 '17 at 13:08










          • @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
            – user2233709
            Nov 19 '17 at 14:23














          up vote
          1
          down vote













          You can’t just write #!$(which foo) because that line is interpreted by the kernel, which does not understand complex syntaxes like $().



          The kernel does not search for the command in the PATH environment variable. That’s why you have to specify the full path to the command.



          The use of /usr/bin/env is a clever hack used to search the command in the PATH. Even if there is a /usr/bin/python3 program, you may for example have installed a more recent version of Python in a different path, for example in you home directory.






          share|improve this answer




















          • Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
            – Vorac
            Nov 19 '17 at 11:03










          • Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
            – user2233709
            Nov 19 '17 at 11:13










          • You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
            – David Favor
            Nov 19 '17 at 13:01










          • @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
            – user2233709
            Nov 19 '17 at 13:08










          • @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
            – user2233709
            Nov 19 '17 at 14:23












          up vote
          1
          down vote










          up vote
          1
          down vote









          You can’t just write #!$(which foo) because that line is interpreted by the kernel, which does not understand complex syntaxes like $().



          The kernel does not search for the command in the PATH environment variable. That’s why you have to specify the full path to the command.



          The use of /usr/bin/env is a clever hack used to search the command in the PATH. Even if there is a /usr/bin/python3 program, you may for example have installed a more recent version of Python in a different path, for example in you home directory.






          share|improve this answer












          You can’t just write #!$(which foo) because that line is interpreted by the kernel, which does not understand complex syntaxes like $().



          The kernel does not search for the command in the PATH environment variable. That’s why you have to specify the full path to the command.



          The use of /usr/bin/env is a clever hack used to search the command in the PATH. Even if there is a /usr/bin/python3 program, you may for example have installed a more recent version of Python in a different path, for example in you home directory.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 19 '17 at 10:56









          user2233709

          603310




          603310











          • Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
            – Vorac
            Nov 19 '17 at 11:03










          • Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
            – user2233709
            Nov 19 '17 at 11:13










          • You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
            – David Favor
            Nov 19 '17 at 13:01










          • @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
            – user2233709
            Nov 19 '17 at 13:08










          • @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
            – user2233709
            Nov 19 '17 at 14:23
















          • Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
            – Vorac
            Nov 19 '17 at 11:03










          • Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
            – user2233709
            Nov 19 '17 at 11:13










          • You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
            – David Favor
            Nov 19 '17 at 13:01










          • @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
            – user2233709
            Nov 19 '17 at 13:08










          • @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
            – user2233709
            Nov 19 '17 at 14:23















          Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
          – Vorac
          Nov 19 '17 at 11:03




          Ahaa, so $() is a shell feature. As well as searching the path, consequently I can't just write #!python3. What about the cross-platform issue. Do we get /usr/bin/env on MacOS? FreeBSD? QNX?
          – Vorac
          Nov 19 '17 at 11:03












          Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
          – user2233709
          Nov 19 '17 at 11:13




          Searching the PATH is not exactly a shell feature; it is a libc feature. That’s only a guess, but /usr/bin/env might be required by the POSIX standard.
          – user2233709
          Nov 19 '17 at 11:13












          You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
          – David Favor
          Nov 19 '17 at 13:01




          You can't use #!$(which foo) because shell expansion does not occur for comments... as in #! (a comment)... This is by specific design. There is no "better" or "best" way to set your interpreter. I tend to use #!/usr/bin/env perl + #!/usr/bin/env ffmpeg, because I build these nightly, against latest source. So in general, you'll use /usr/bin/env when you have multiple copies of a program in your $PATH + you'd like to take the highest precedence version (one appearing first in your $PATH variable).
          – David Favor
          Nov 19 '17 at 13:01












          @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
          – user2233709
          Nov 19 '17 at 13:08




          @DavidFavor It does not matter that it’s a comment, it matters that it is a special kernel feature.
          – user2233709
          Nov 19 '17 at 13:08












          @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
          – user2233709
          Nov 19 '17 at 14:23




          @MarkPlotnick Are you sure it is a feature of the shell? I just gave it a try, and could also run that shell script through /usr/bin/env…
          – user2233709
          Nov 19 '17 at 14:23


          -

          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Image
          Clash Royale CLAN TAG #URR8PPP up vote 1 down vote favorite I'm using WordPress 4.9.8, CiviCRM to 5.5.1, I usually send email to contact by Search> Find contacts View contact details Action> Send email Send email ok, Contact received mail ok like picture But status only Email sent though contact read email or not. So, can CiviCRM can change status to Email read when contact read email? wordpress email share | improve this question asked Sep 26 at 0:12 ToanLuong 49 9 add a comment  |  up vote 1 down vote favorite I'm using WordPress 4.9.8, CiviCRM to 5.5.1, I usually send email to contact by Search> Find contacts View contact details Action> Send email Send email ok, Contact received mail ok like picture But status only Email sent though contact read email or not. So, can CiviCRM can change status to Email read when contact read email? wordpress email share | improve this questi...
          Read more

          Displaying single band from multi-band raster using QGIS

          Image
          Clash Royale CLAN TAG #URR8PPP 1 How can I extract a single band from multi-band raster in QGIS? I have an remote sensed image which has 6 bands (including NDVI band), I want to display each band separately, but have no idea how to do. I have seen some questions similar here but none worked for me. The original image (has 6 bands) is: I want to display the band 6 which should be like this: But I tried gdal_translate, and couldn't get the correct result. What I have got is: qgis raster multi-band share | improve this question edited Mar 5 at 0:53 Summer asked Mar 4 at 6:42 Summer Summer 23 6 Is this any help gis.stackexchange.com/questions/220658/… ? if not gis.stackexchange.com/questions/62133/… might help. – Michael Stimson Mar 4 at 6:46 Thanks for answering but when I used gdal_translate, qgis showed that 'Error 4: Kayena.tif: No such file or directory". Would you know how to fi...
          Read more

          How many registers does an x86_64 CPU actually have?

          Image
          Clash Royale CLAN TAG #URR8PPP up vote 2 down vote favorite I am currently learning reverse engineering and am studying the flags register. I had in my mind that rflags was just another name for one of the 16 general purpose registers, for example rax or rbx . But it looks like rflags is actually an additional register. So that makes 17 registers in total... how many more could there be? I have spent at least an hour on this and found numerous different answers. The best answer so far is this, which says that there are 40 registers in total. 16 General Purpose Registers 2 Status Registers 6 Code Segment Registers 16 SSE Registers 8 FPU/MMX Registers But if I add that up, I get 48. Could anybody provide an official answer on how many registers an x86_64 CPU has (e.g. an Intel i7). Additionally, I have seen references to 'hardware' and 'architectural' registers. What are those registers and how many are there? register x86-64 share | improve this...
          Read more