This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
The page, with its #!/bin/cat shebang example, states parenthetically that the resulting quine is "illegal." Does anyone know what the author means by this? Jesuswaffle 19:00, 15 July 2006 (UTC)
It don't work :)
root@jurp5-server:~# cat test #!/bin/cat Any text can be placed below the shebang. root@jurp5-server:~# chmod +x test root@jurp5-server:~# ./test #!/bin/cat Any text can be placed below the shebang.
I am redirecting "Pound bang" to this article. Mbarbier 05:47, 16 November 2006 (UTC)
Why is the path to ruby specified as /bin/ruby? I have yet to see it installed there, rather in /usr/bin, nor can I see why it should be in /bin. Yselkowitz 03:23, 29 January 2007 (UTC)
Please comment and/or correct: The word "sharp" may also have been taken from music, where the same sign is used to indicate certain tone shifts, e.g. "F#" for "F sharp".]
-> unlikely, as the hash is the standard quote on uniq and the header of a program is a quote. —Preceding unsigned comment added by 193.29.186.1 ( talk) 14:32, 4 September 2007 (UTC)
-> how is the hash a quote?
An other way of writing Shebang ? Sha-Bang
The article begins with "... shebang (also called a hashbang, hashpling, or pound bang) ...". We're never going to find a reliable secondary source as to these alternative pronunciations, so I thought I'd try Google:
So, although I sincerely doubted the last, it looks like all four are in fact in fairly common usage. If we were to drop any one, it possibly ought to be hashpling, but at least the first page of hits looked like they were mostly on-topic and relevant. So, hey-ho, no edit needed at this time, I think. -- Nigelj ( talk) 17:43, 19 May 2009 (UTC)
Does anyone else think there should be a mention of the BOM ( Byte order mark) as it's apparently been known to cause problems on Unix systems because of the meaning of the shebang? Most online mentions and explanations of BOMs mention Unix problems for this reason. 217.166.94.1 ( talk) 08:35, 16 October 2009 (UTC)
This article has received virtually all of the content from interpreter directive which had a duplicate discussion of this (shebang) topic. The title of that article (interpreter directive) is much more encompassing than just the #! sequence. An interpreter directive is any language construct that controls the interpreter of a computer language, as properly stated by the reference that was included there already, but completely ignored. As a result THIS article needs major cleanup work to reduce duplication, fix content order, and linguistic problems. Kbrose ( talk) 16:39, 30 September 2010 (UTC)
I don't see what needs cleanup; the article seems quite well written in terms of flow, style, grammar, spelling and formatting. There are several tags for original research, but that's not cleanup. I see that the "cleanup" tag was added on 2010-09-30 (about 10 days ago) by Kbrose, and was changed to "Cleanup October 2010" on 2010-10-06. - Pgan002 ( talk) 02:25, 11 October 2010 (UTC)
The path to the file being executed seems to be passed as an argument to the invoked program, not as standard input. All the external links seem to agree on this point. —Preceding unsigned comment added by 66.252.152.202 ( talk) 14:27, 18 October 2010 (UTC)
149.125.193.90 recently made a change to rewrite an example from
#!/usr/bin/perl -w
to
#!/usr/bin/env perl -w
indicating in the comment that this was to "promote good coding standards." I'm baffled why this is better in any way. I know for sure I've never heard of this as a good coding standard. All it appears to do is cause env to be run which in turn runs perl, meaning all it does is create one more process to do something that could run just fine without the extra process. About the only reason I can think of to do this is if you're sure about the full path to env but not about perl. I've asked on the editor's talk page if he could explain further but have not seen a response.
I'm not a perl expert, so I don't want to undo this change without asking first. But this doesn't look right to me. Comments, please? Msnicki ( talk) 21:55, 4 November 2010 (UTC)
#!perl -w
". Perhaps you or someone else knows if that's likely to work on other Unix or Unix-like systems.
Msnicki (
talk)
19:17, 5 November 2010 (UTC)The article claims that the executable specified following the shebang must have a full path and that if it's not known, then env can be used to search the path directories. But having tested it, I know for sure that on OSX, at least, you can specify a simple command name and it will search the path directories on its own. Is this unusual? Or is it possible that the full path requirement is something that's been fixed on most or all modern Unix or Unix-like systems? Are there any variants known for sure not to support path searches? Msnicki ( talk) 03:08, 7 November 2010 (UTC)
Shebang is currently being used in the URLs of New Twitter and Facebook, for some reason. Unsure if this is related, but might be worth a mention. phocks ( talk) 14:18, 27 January 2011 (UTC)
The first example in the Purpose section seems not clear enough or is accompanied with incorrect wording. With the user input foo bar as parameters, the foo is the parameter $1, and the bar is the parameter $2 (the script-file itself is at $0). So the passage with bar provided as a parameter $1 is not true. Also, it's not clear why -x flag should substitute /usr/local/bin/foo for foo. It looks like the resulting command output should be $ /bin/sh -x /usr/local/bin/foo foo bar. Or am I missing something? Anyway, for the sake of clarity, I'd recommend to abstain from using the same name for the script and its parameter. Any meaningful name will be ok, such as selfprint, debugme, or similar. 81.25.53.102 ( talk) 15:45, 24 March 2011 (UTC)
(Regarding the revert 442196518: "Let's stay consistent with the usage in the first sentence. "Number sign" is more widely understood as the name of the symbol.", in response to "'The name "hash" is common in North America when reading computer text out loud when it is used to denote a comment.', says number sign, and this is a comment")
I just wanted to say that's fair enough; I thought hash would be clearer, but it does make sense to keep it as 'number sign' to match the 'exclamation point', so it may as well stay as is (ie. as 'number sign'). The one thing I want to mention, though, is a quote from the 'number sign' page:
You're quite sure that 'number sign' is the more widely understood name for the # symbol? :-) -- 82.70.156.254 ( talk) 20:21, 31 July 2011 (UTC)
The Examples section currently has a sentence about /bin/sh (the Bourne shell) being a link to bash. In its current form, it says:
However, the Portability section says this:
These appear to differ on two major points:
(On my system, /bin/sh is a symlink, but it points to dash...) Now, it's entirely possible that both sections are correct for different cases -- different examples of the "many" Linux systems referenced, different bash features, etc. But then the differences need to be clarified. -- Perey ( talk) 12:14, 16 October 2011 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
The page, with its #!/bin/cat shebang example, states parenthetically that the resulting quine is "illegal." Does anyone know what the author means by this? Jesuswaffle 19:00, 15 July 2006 (UTC)
It don't work :)
root@jurp5-server:~# cat test #!/bin/cat Any text can be placed below the shebang. root@jurp5-server:~# chmod +x test root@jurp5-server:~# ./test #!/bin/cat Any text can be placed below the shebang.
I am redirecting "Pound bang" to this article. Mbarbier 05:47, 16 November 2006 (UTC)
Why is the path to ruby specified as /bin/ruby? I have yet to see it installed there, rather in /usr/bin, nor can I see why it should be in /bin. Yselkowitz 03:23, 29 January 2007 (UTC)
Please comment and/or correct: The word "sharp" may also have been taken from music, where the same sign is used to indicate certain tone shifts, e.g. "F#" for "F sharp".]
-> unlikely, as the hash is the standard quote on uniq and the header of a program is a quote. —Preceding unsigned comment added by 193.29.186.1 ( talk) 14:32, 4 September 2007 (UTC)
-> how is the hash a quote?
An other way of writing Shebang ? Sha-Bang
The article begins with "... shebang (also called a hashbang, hashpling, or pound bang) ...". We're never going to find a reliable secondary source as to these alternative pronunciations, so I thought I'd try Google:
So, although I sincerely doubted the last, it looks like all four are in fact in fairly common usage. If we were to drop any one, it possibly ought to be hashpling, but at least the first page of hits looked like they were mostly on-topic and relevant. So, hey-ho, no edit needed at this time, I think. -- Nigelj ( talk) 17:43, 19 May 2009 (UTC)
Does anyone else think there should be a mention of the BOM ( Byte order mark) as it's apparently been known to cause problems on Unix systems because of the meaning of the shebang? Most online mentions and explanations of BOMs mention Unix problems for this reason. 217.166.94.1 ( talk) 08:35, 16 October 2009 (UTC)
This article has received virtually all of the content from interpreter directive which had a duplicate discussion of this (shebang) topic. The title of that article (interpreter directive) is much more encompassing than just the #! sequence. An interpreter directive is any language construct that controls the interpreter of a computer language, as properly stated by the reference that was included there already, but completely ignored. As a result THIS article needs major cleanup work to reduce duplication, fix content order, and linguistic problems. Kbrose ( talk) 16:39, 30 September 2010 (UTC)
I don't see what needs cleanup; the article seems quite well written in terms of flow, style, grammar, spelling and formatting. There are several tags for original research, but that's not cleanup. I see that the "cleanup" tag was added on 2010-09-30 (about 10 days ago) by Kbrose, and was changed to "Cleanup October 2010" on 2010-10-06. - Pgan002 ( talk) 02:25, 11 October 2010 (UTC)
The path to the file being executed seems to be passed as an argument to the invoked program, not as standard input. All the external links seem to agree on this point. —Preceding unsigned comment added by 66.252.152.202 ( talk) 14:27, 18 October 2010 (UTC)
149.125.193.90 recently made a change to rewrite an example from
#!/usr/bin/perl -w
to
#!/usr/bin/env perl -w
indicating in the comment that this was to "promote good coding standards." I'm baffled why this is better in any way. I know for sure I've never heard of this as a good coding standard. All it appears to do is cause env to be run which in turn runs perl, meaning all it does is create one more process to do something that could run just fine without the extra process. About the only reason I can think of to do this is if you're sure about the full path to env but not about perl. I've asked on the editor's talk page if he could explain further but have not seen a response.
I'm not a perl expert, so I don't want to undo this change without asking first. But this doesn't look right to me. Comments, please? Msnicki ( talk) 21:55, 4 November 2010 (UTC)
#!perl -w
". Perhaps you or someone else knows if that's likely to work on other Unix or Unix-like systems.
Msnicki (
talk)
19:17, 5 November 2010 (UTC)The article claims that the executable specified following the shebang must have a full path and that if it's not known, then env can be used to search the path directories. But having tested it, I know for sure that on OSX, at least, you can specify a simple command name and it will search the path directories on its own. Is this unusual? Or is it possible that the full path requirement is something that's been fixed on most or all modern Unix or Unix-like systems? Are there any variants known for sure not to support path searches? Msnicki ( talk) 03:08, 7 November 2010 (UTC)
Shebang is currently being used in the URLs of New Twitter and Facebook, for some reason. Unsure if this is related, but might be worth a mention. phocks ( talk) 14:18, 27 January 2011 (UTC)
The first example in the Purpose section seems not clear enough or is accompanied with incorrect wording. With the user input foo bar as parameters, the foo is the parameter $1, and the bar is the parameter $2 (the script-file itself is at $0). So the passage with bar provided as a parameter $1 is not true. Also, it's not clear why -x flag should substitute /usr/local/bin/foo for foo. It looks like the resulting command output should be $ /bin/sh -x /usr/local/bin/foo foo bar. Or am I missing something? Anyway, for the sake of clarity, I'd recommend to abstain from using the same name for the script and its parameter. Any meaningful name will be ok, such as selfprint, debugme, or similar. 81.25.53.102 ( talk) 15:45, 24 March 2011 (UTC)
(Regarding the revert 442196518: "Let's stay consistent with the usage in the first sentence. "Number sign" is more widely understood as the name of the symbol.", in response to "'The name "hash" is common in North America when reading computer text out loud when it is used to denote a comment.', says number sign, and this is a comment")
I just wanted to say that's fair enough; I thought hash would be clearer, but it does make sense to keep it as 'number sign' to match the 'exclamation point', so it may as well stay as is (ie. as 'number sign'). The one thing I want to mention, though, is a quote from the 'number sign' page:
You're quite sure that 'number sign' is the more widely understood name for the # symbol? :-) -- 82.70.156.254 ( talk) 20:21, 31 July 2011 (UTC)
The Examples section currently has a sentence about /bin/sh (the Bourne shell) being a link to bash. In its current form, it says:
However, the Portability section says this:
These appear to differ on two major points:
(On my system, /bin/sh is a symlink, but it points to dash...) Now, it's entirely possible that both sections are correct for different cases -- different examples of the "many" Linux systems referenced, different bash features, etc. But then the differences need to be clarified. -- Perey ( talk) 12:14, 16 October 2011 (UTC)