Talk:Shebang (Unix)

message: Perhaps you were looking for : Ricky Martin - She Bangs! https://www.youtube.com/watch?v=5ihtX86JzmA 207.216.37.201 (talk) 06:51, 22 May 2015 (UTC)
thread_title:  Disambiguation 

message: I can't work out what the last sentence in the lead paragraph is saying:
The "shebang" or "hashbang" name is also sometimes used of state-preserving fragment identifiers in Ajax applications; Google Webmaster Central specifies that fragment identifiers starting with an exclamation point (...url#!state...) are indexed specially by the Googlebot.
Should this be 'sometimes used in', 'sometimes used as', or 'sometimes used instead of' or something else? 81.98.43.107 (talk) 17:11, 1 February 2012 (UTC)
replies: text: Clarified a bit. Lorem Ip (talk) 00:25, 2 February 2012 (UTC)
thread_title:  Ajax 

message: I think the phrasing about env security is unnecessarily convoluted. It is also a quite free interpretation of the source. My understanding is that the env approach is dangerous only if you use it for suid programs (or similar) without checking PATH, which is a recipe for disaster anyway. --LPfi (talk) 12:05, 27 April 2012 (UTC)
replies: text: Agreed. I’ve introduced some alternative wording. Ewx (talk) 07:44, 28 April 2012 (UTC)
thread_title:  env security 

message: The page now says "UTF-8 can reliably be recognised as such by a simple algorithm".
This is wrong - UTF-8 cannot be distinguished reliably from any other encoding which uses 8bit per character unless that file happens to contain an invalid UTF-8 sequence. As an example, "aÃ¨!" in ISO-8859-1 is "aè!" if read as UTF-8. There is no way for an algorithm to say it's one way or the other.  — Preceding unsigned comment added by 188.65.1.1 (talk) 10:33, 31 May 2012 (UTC)
replies: text: If there are more than a few non-ASCII bytes and there is no invalid UTF-8, the probability that it is not UTF-8 is very low. No mathematical evidence is needed.--BIL (talk) 11:08, 31 May 2012 (UTC)
replies: text: Might be reported to UTF-8 page?  — Preceding unsigned comment added by 84.100.195.219 (talk) 23:37, 22 June 2012 (UTC)
thread_title:  UTF-8 indentification 

message: Some people say the BOM indication is unneeded to them in UTF-8, as UTF-8 as no specific Byte Order. 
On old Unix, Shebang is not compatible with BOM.
Nowadays, text files are generally written in UTF-8, and often with BOM.
This makes some files, those with both BOM and shebang not to work on old Unix.
But scripts with both BOM and shebang can still be launched indicating the interpreter to use on the command line.
So my question:
How is Shebang unneeded as the interpreter generally known and provided by the caller?  — Preceding unsigned comment added by 77.199.89.101 (talk) 13:36, 2 July 2012 (UTC)
replies: text: The wrappers in libc (execvp, etc) will attempt to use the shell if execve does not recognize the file format.  So arguably there is some (limited) guessing going on. Ewx (talk) 10:35, 3 February 2013 (UTC)
thread_title:  Unneeded Shebang 

message: The existing examples are repetitive, mostly "me-toos" which are uninteresting because they are conventional scripting languages.  Pruning those and adding a few different examples such as "make" and "env" would benefit the reader. TEDickey (talk) 10:02, 13 July 2012 (UTC)
replies: text: I agree with this.  The point of the examples is to demonstrate use of #!, not to enumerate everything you can possibly use it with (for which a category would make more sense).  The article does not need multiple shells and multiple scripting languages in its examples. Ewx (talk) 07:53, 20 May 2013 (UTC)

text: I strongly disagree, the flags for each program differ widely as to how the program is written on the first line of a script (sed, awk and csh need a -f and tcc needs -run while other programs don't need options at all (PHP, Python) and even more programs require other options. (scsh, this) (guile, -s) (gs, -dNOSAFER) ), and a brief list of how to use different programs' options (including all of the common ones (awk, etc.) that require options) is helpful to have. I don't read it as "me-too," I read it as "This is how to invoke this common program in a script." Maybe this should be rewritten more clearly. TL,DR: We should list the programs that require flags after the shebang in the examples section. -- 12.218.76.10 (talk) 17:04, 26 October 2014 (UTC)
replies: text: That would be a completely open ended list, and could easily become longer than the rest of the article put together.  People who want to know how to script in a particular language should read a tutorial for that language. Ewx (talk) 09:03, 28 October 2014 (UTC)
replies: text: I doubt it would be longer than a paragraph. After all, many or most of the programs either don't require any options or just require '-f' or another small option or two, with the exceptions above. If it does get too long, we could always come up with some kind of limitation. (most-popular languages list or some such thing.) -- 12.218.76.10 (talk) 17:08, 3 November 2014 (UTC)
thread_title:  Examples 

message: For the record, I believe I was the one to coin this particular usage of "shebang", sometime in the late 1980s.  By the time I posted  in 1989 I was already trying to get people to adopt the term. (The Usenet article in question was patch 7 for Perl 3.0.) I'm not aware that anyone else coined it independently, though of course that is always possible.  (Sorry for the anonymous post, but someone seems to have grabbed "TimToady" already, and I don't think it was me.)  --Larry Wall 71.139.24.65 (talk) 02:49, 4 September 2012 (UTC)
replies: text: since the slang word shebang was in fairly widespread use prior to computer culture, were you aware of that usage? I would trace the whole shebang back to that word, seems unavoidable. 68.174.97.122 (talk) 14:12, 22 February 2013 (UTC)
thread_title:  Coining of "shebang" (to mean #!) 

message: Neither this article nor Interpreter directive is noteworthy enough for a wikipedia article really, but if we merge them together they might just pass. Felixphew (Ar! Ar! Ar!) 07:16, 19 June 2014 (UTC)
replies: text: Except for UNOS (1982) #! is not an interpreter directive but a kernel feature. Schily (talk) 13:23, 14 July 2014 (UTC)
thread_title:  Proposed merge with [[Interpreter directive]] 

message: It would be nice if this article would mention how a shebang shell script can set a variable to a pathname to the script. This pathname is useful so the script can use relative paths to reference other files it needs. I have shell code to do this, but it isn't pretty and I'm not sure it's robust. Perhaps someone knows a bulletproof way to do this and could add it to this article.Encyclopedant (talk) 08:23, 6 December 2014 (UTC)
replies: text: That depends on the language used and is nothing to do with #!.  In general consult a tutorial or reference documentation for your choice of language. Ewx (talk) 09:41, 6 December 2014 (UTC)

text: There have been many discussions in the POSIX standard teleconferences and the reason why this feature is not yet integrated in the standard is that there is currently no suitable proposal to deal with variable path names. Note that the POSIX standard does not specify pathnames and that #! <command> needs an absolute path name for <command> in order to avoid making it a security problem. Schily (talk) 17:09, 8 December 2014 (UTC)
thread_title:  the pathname of the script 

message: Based on all the talk at Interpreter directive, the answer is clearly a no to the merge of the two. One is a list, the other gives details and history. The point was made there are different versions. I will wait a short time before removing this request that is not an agreement. Tag removed. Telecine Guy 04:50, 26 October 2015 (UTC)
thread_title: Merge

message: #!path arg translates to this system call: execve("path", ["path", "arg"], env);
According to this link, most unices deliver all argument in single string.  — Preceding unsigned comment added by 218.103.114.193 (talk) 08:17, 28 October 2015 (UTC)
thread_title:  Too Linux Centric? 

message: What topic would one look under in the 'man' command to find information about shebang?Tedtoal (talk) 20:57, 21 December 2016 (UTC)
replies: text: Under Linux, man execve. Ewx (talk) 09:15, 22 December 2016 (UTC)
thread_title:  man topic? 

message: IMHO any characters before #! also shall be ommited in first line. Without it there is not possible to run part of script interpreters correctly. 
For example: 
for php shall be possible: 
//#!/bin/.../php
or
 
/*#!/bin/.../php
*/
to prevent put "#!/bin/.../php" to stdout after script running.  — Preceding unsigned comment added by 94.254.137.147 (talk) 23:51, 26 May 2017 (UTC)
replies: text: You might be interested in this StackOverflow post. The hack works on Unix-like systems for languages where forward slash is comment. It treats the file as a shell script and run the first line, which in turn runs the "interpreter" then immediately exits.  --2601:647:4E03:9530:DC98:4A8E:FE3E:1CBA (talk) 10:13, 1 May 2020 (UTC)
thread_title:  characters before shebang 

message: There seems to be a missing footnote or subsequent text referred to in this article:
"On a system with setuid script support this will reintroduce the race eliminated by the /dev/fd workaround described below."
(I couldn't find another occurrence of either "/dev/fd" or "workaround".)
Cburley (talk) 21:29, 13 August 2018 (UTC)
thread_title:  Missing "/dev/fd workaround, discussed below" 

message: #!/bin/bash as an example without comment is not a a good idea. Yes, it can be found in some tutorials and scripts, but that doesn't mean it's right. We don't show wrong JavaScript codes as example, do we? The use of paths to the binary is not recommended because the path might differ - as explained in section Portability. #!/usr/bin/env bash should be shown instead. But because #!/usr/bin/bash is actually widely used (and because those are just examples) the best approach would be to mention both. That's basically what the IP did (and what I repeated after it was reverted). WP:NOTGUIDE does not apply here. The reverted text was not an instruction or manual but a clarification. Otherwise the whole section about protability should be removed too. --StYxXx ⊗ 07:45, 14 April 2020 (UTC)
replies: text: Well, why not show just the recommended way, just like the Python case below it? There is no need to show anything else, and as you say the explanation comes later. As it was, the corollary looked like a guide and editorial.Dorsetonian (talk) 10:21, 14 April 2020 (UTC)
replies: text: I also think that the Bash example should look like the Python example. Of course WP is not a guide, and that is why the text should not say anything like "this is the recommended way". But superior, more generally applicable examples should still be preferred to inferior, less likely to work ones. The downside of /bin/bash is that it does not work on systems where Bash lives elsewhere. The downside of the `env` way is that it *may* pick up the wrong interpreter. In my experience, the former bites far more often and is more difficult to work around than the latter. If simplicity is desired, the `/bin/sh` example provides that. --RainerBlome (talk) 12:46, 26 April 2020 (UTC)
thread_title:  Reverts (#!/bin/bash example) 

message: The current page is inconsistent in that it is written in the "definition" that the shebang is
 #!interpreter ...
"where interpreter is an absolute path...", but later in the page it's written "...or relative to the current working directory".
Now what?! It would indeed be handy to allow relative paths like "./myscript" or "../myscript" where myscript would be a user script that interprets the actual file with "custom commands" or data. Now why did the author put "absolute" if it is not necessarily an absolute path? And/or why would one say "...absolute... or relative..."? (OK, hoping that it is true, it is indeed less bad to write "A or not A" rather than wrongly "must be A"...) — MFH:Talk 22:57, 4 May 2020 (UTC)
thread_title:  only absolute or also relative path?