Talk:Shebang (Unix)/Archive 1

Archive 1

#!/bin/cat Shebang Quine "Illegal?"

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)

Not sure. You'd have dig further into what is a quine and what methods are allowed. To me it looks perfectly valid, though it's perhaps an abuse of the unix interpreter mechanism - still, it only adds to it's hack value. Misza13 ^{T C} 15:47, 15 July 2006 (UTC)

I've done some more research, and I can't find any justification in the sources I've looked at for calling this quine "illegal." Apparently GreyCat was the one who inserted the note. I'm kind of new to this, so I'm not sure if there's a process for getting his attention. Jesuswaffle 19:17, 15 July 2006 (UTC)

I believe that it was User:Jleedev who added that line: http://wiki.riteme.site/w/index.php?title=Shebang_%28Unix%29&diff=61690762&oldid=61170953 . To my best knowledge, quine may be called "illegal" by some people if it accesses disk files to read itself. Running /bin/cat surely reads disk files. --GreyCat 11:06, 4 October 2006 (UTC)

A quine is a self-reproducing sentence (or program), which typically contains a copy of itself. The cat example is technically a "pure" quine, in that anything the user types to stdin will be duplicated to stdout. On the other hand, it's not really a quine program at all, since it contains no executable code (apart from invoking cat). — Loadmaster 15:48, 5 December 2006 (UTC)

The cat example is "illegal" because the text line following the shebang line is not data that is read by the cat program, but is a shell command line; since the cat program is invoked in place of the shell, the text line is never read (by either sh or cat). It's probably more correct just to say that any lines past the shebang of cat are ignored. — Loadmaster 15:55, 5 December 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.

Merge

I am redirecting "Pound bang" to this article. Mbarbier 05:47, 16 November 2006 (UTC)

/bin/ruby vs. /usr/bin/ruby

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)

sharp like shifting a tone

[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?

Sha-Bang

An other way of writing Shebang ? Sha-Bang

Also called...

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:

shebang

872,000 hits

hashbang

24,600 hits

hashpling

889 hits

"pound bang"

2,970 hits

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)

Should be pointed out that there are 781,000 results for the phrase "whole shebang" (meaning everything) so programming related results of "shebang" are probably nearer 90,000 at most. 81.17.65.146 (talk) 16:12, 1 July 2009 (UTC)

The spelling shabang seems to get about 1,000 ghits referring the *nix usage; don’t know if that makes it notable. Is crunchbang something that ever had any real currency, or is this just something that’s come into vogue since the distro? —Wiki Wikardo 10:09, 28 December 2009 (UTC)

Problem with BOM

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)

Merge executed

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)

Cleanup what?

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)

Dubious

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)

This can be easily verified by making an empty script with shebang `#!/bin/echo`. When this script is run, the program name is printed. The article should be fixed. Kingping (talk) —Preceding undated comment added 20:02, 2 November 2010 (UTC).

Be bold. You're obviously right. Do you have time to fix that part? Many will appreciate it. Msnicki (talk) 20:43, 2 November 2010 (UTC)

"Promoting good coding"?

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 may not be installed in /usr/bin/perl. It could be elsewhere, e.g. /usr/local/bin/perl or in your home directory if you compiled from sources. "#!/usr/bin/env perl" works in such cases, but "#!/usr/bin/perl" fails. -- X7q (talk) 22:06, 4 November 2010 (UTC)

There's an error though. You can't pass -w in "#!/usr/bin/env perl -w". It's interpreted as part of command's name and not as a switch. -- X7q (talk) 22:17, 4 November 2010 (UTC)

I agree, it doesn't work. (I tried it, too.) Based on that, do you agree this edit should be reverted? Msnicki (talk) 16:11, 5 November 2010 (UTC)

Yeah, I think it's better to revert: 1) because of the error with -w, 2) here's one opinion that using #!/usr/bin/env is not always the right thing to do. So it's really debatable whether #!/usr/bin/env is good coding or not. -- X7q (talk) 18:58, 5 November 2010 (UTC)

Thanks, X7q. Done. Fwiw, it appears (at least on OSX) that if all you want is for the PATH directories to be searched, a simpler answer is simply to write "#!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)

Which systems require a full path?

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)

Doesn't work on Linux and FreeBSD. So it's probably just an OS X feature. -- X7q (talk) 13:11, 7 November 2010 (UTC)

OS X requires a full path too. Example: http://pastebin.com/5FakUwbS Ewx (talk) 22:08, 12 January 2011 (UTC)

Use in URLs like Facebook and Twitter

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)

It's not related. See http://code.google.com/web/ajaxcrawling/docs/getting-started.html for details.Ewx (talk) 09:17, 28 January 2011 (UTC)

Well, then, in this case I think there should at least be a reference that this is *not* related but rather that the use of the "hashbang" characters in URLs is to make AJAX-based web applications crawlable by search engines, no? Mabuse (talk) 14:36, 24 February 2011 (UTC)

The URL hashbang needs its own article, and Hashbang needs a disambiguation page. The magic characters at the start of *nix scripts are probably less important and much less visible to the majority of readers than a ubiquitous part of every URL from Twitter and Facebook. (I say “less important” since those of us that know what they are can operate without them, whereas #! won’t be disappearing from Twitter and Facebook!). nemo (talk) 17:19, 31 May 2011 (UTC)

Example in the Purpose section

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)

Thank you for your suggestion. When you believe an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). ¦ Reisio (talk) 16:07, 24 March 2011 (UTC)

I don't like the idea of such "blind" collaboration: someone adds whatever he wants on his own discretion, then someone else removes this in the same way, and so forth... No one (a single person) may have a belief strong enough to change the worldwide encylopedia on his own. IMHO, the process of making changes would benefit from discussions, in community, settled down aforehand. And the talk page is a perfect place for this. So I've pointed out some possible problems, and would like to see some comments on the subject, in order to decide if the changes are necessary indeed. 81.25.53.102 (talk) 19:53, 24 March 2011 (UTC)

'Number sign' vs 'Hash'

(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:

'In the United States, the symbol is usually called the pound sign ... In Canada, this key is most frequently called the number sign key. In most other English-speaking countries the symbol is usually called the hash, and in Ireland, the UK, Australia, India, South Africa, Singapore and New Zealand the telephone key is called the hash key. ... In many parts of the world, including parts of Europe, Canada, Australia, and Russia, number sign ... refers instead to the numero sign ... The name "hash" is common in North America when reading computer text out loud when it is used to denote a comment.'

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)

/bin/sh linked to bash?

The Examples section currently has a sentence about /bin/sh (the Bourne shell) being a link to bash. In its current form, it says:

On many systems, /bin/sh is linked to bash. When invoked in this manner, many features of bash are disabled, to comply with POSIX.

However, the Portability section says this:

In many Linux systems and recent releases of Mac OS X, /bin/sh is a symbolic link to /bin/bash, the Bourne Again shell. Using syntax specific to bash while maintaining a shebang pointing to the Bourne shell is not portable.

These appear to differ on two major points:

1. Is the link a symlink or a hard link?
2. Does this usage disable non-POSIX features of bash (and so presumably preserve portability), or are bash-only features still able to be invoked?

(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)

The kind of link is completely immaterial! The behaviour when invoked as sh is described in the man page, and the article could probably do with checking against the manual here. That said this is supposed to be an article about #! not Bash, so one has to wonder whether the minutiae of a particular shell’s behaviour really belongs here at all. Ewx (talk) 07:59, 17 October 2011 (UTC)

1. Whether the link is hard or symbolic should be irrelevant. It might vary between distributions and installations. If it is a hard link, then they must be on the same partition. While a symbolic link could point elsewhere, the point of having /bin/sh on the root device is that it is always available, and so the symbolic link should also point to the same partition.
2. Bash tries to behave portably when invoked as /bin/sh. Mainly it will correctly execute POSIX shell scripts, but happily execute bashisms which would be illegal in the Bourne shell. So it will work for portable shell scripts but not for testing portability.

I did add a reference citing the man page. I think lots of #!s are used to invoke bash, so there is good reason to say something about the issues, and what is said should be correct.

--LPfi (talk) 14:47, 17 October 2011 (UTC)