LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices

Reply
 
Search this Thread
Old 04-11-2013, 06:56 PM   #16
Nbiser
Member
 
Registered: Oct 2012
Location: Maryland
Distribution: Fedora, Slackware, Debian, Ubuntu, Knoppix, Helix,
Posts: 279
Blog Entries: 7

Rep: Reputation: 41

Quickly, back to your first question. Though it isn't strictly necessary to use the shebang, it is better safe than sorry. Some systems may not know where to go or what to do with the script. So, if you know the system that the script is for doesn't need a shebang, you don't, need to use it. But if you don't know for sure, you better use it.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 04-11-2013, 10:28 PM   #17
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,342

Rep: Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575
Quote:
Originally Posted by moraxu View Post
Then the following quote:
from here is erroneous, since the exec call always fails in that case?
It depends. The exec() call itself will always fail. Whether there is a fallback to invoke /bin/sh depends on what was compiled into the program making the call. Well-behaved utilities (e.g., find with the "-exec" option, awk invoking an external process) do, when they see the ENOEXEC error, invoke /bin/sh to interpret the file. awk actually goes the extra mile and reads the beginning of the file first to see if it looks like a script, rather than a binary perhaps intended for a different OS or architecture. But none of that behavior is anything that is built into the library, and certainly not part of the system call itself, making it very much a YMMV thing.

Last edited by rknichols; 04-11-2013 at 10:31 PM.
 
1 members found this post helpful.
Old 04-13-2013, 12:56 PM   #18
i92guboj
Gentoo support team
 
Registered: May 2008
Location: Lucena, Córdoba (Spain)
Distribution: Gentoo
Posts: 4,036

Rep: Reputation: 372Reputation: 372Reputation: 372Reputation: 372
Well, those are are just conventions as noted above... Nothing stops you from writing a program that probes for file types. You could programatically try to load it as a word document or as an image file even if exec() fails... So, the best thing is not to assume anything, and, again, write the damned shebang. In the extension that this thread has already, we could write like a couple thousands of shebang lines :P
 
Old 04-13-2013, 01:56 PM   #19
PTrenholme
Senior Member
 
Registered: Dec 2004
Location: Olympia, WA, USA
Distribution: Fedora, (K)Ubuntu
Posts: 4,147

Rep: Reputation: 330Reputation: 330Reputation: 330Reputation: 330
Do note that /bin/sh is usually identical to /bin/bash with POSIX restrictions enabled. (That is "built in" to the bash executable, and is based on the name with which bash is called. /bin/sh is usually just a symlink to bin/bash.)
 
Old 04-14-2013, 02:03 AM   #20
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,243
Blog Entries: 15

Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by moraxu View Post
But what if we choose the Run option?

Is there a way to find out which shell is the default one in case of shebang on my specific distribution? Or maybe this shell is equivalent to user's login one?
Create a script that would echo the shell's signatures like echo "$0" > ~/shell-info or cat "/proc/$$/cmdline" > ~/shell-info.txt; then run it.

And perhaps ps u "$$" as well. Or perhaps check shell-specific variables like "$BASH", "$BASH_VERSION", and "$BASHPID".

Last edited by konsolebox; 04-14-2013 at 02:07 AM.
 
Old 04-14-2013, 10:48 AM   #21
David the H.
Bash Guru
 
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Debian sid + kde 3.5 & 4.4
Posts: 6,823

Rep: Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946
Quote:
Originally Posted by PTrenholme View Post
Do note that /bin/sh is usually identical to /bin/bash with POSIX restrictions enabled.
This can't be relied upon to be true. Many distributions like Debian are now setting /bin/sh to be dash by default, which is a very strict POSIX shell.

You can never be certain what will happen if you use non-POSIX features (e.g. arrays) inside a /bin/sh script. Some interpreters will continue accept them if they support them, but others will choke. It all depends on which interpreter the system is set to use, and whether the code in question is actually anti-posix or just undefined according to it.

In short, when writing #!/bin/sh scripts, always stick to POSIX-defined code only. If you want to use the features of a specific shell features, your shebang needs to explicitly point to that interpreter.
 
Old 04-14-2013, 06:14 PM   #22
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,225

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
As above, in fact I'd go with the even shorter version
Quote:
If you want to use the features of a specific shell features, your shebang needs to explicitly point to that interpreter.
and say always specify the shell you want, unless you are just messing about and know what your current shell really is/does.
See my previous post about PROD systems
 
Old 04-15-2013, 10:32 AM   #23
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 1,986

Rep: Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512
The key is "the default is usually the /bin/sh"...

If the program invoking the script (via exec) is programmed to use the default then it is true.

If it is is not programmed, then no default exists, the "usually" is for the case where there is a default.

Granted, the sentence is not as clear as it could be. This particular "default" only exists in command line shells... it doesn't exist anywhere else.

The system call execve (lies at the base of all the exec calls) has the kernel perform all "#!" interpretations. If either "#!" doesn't exist, OR the name of the executable following the #! doesn't exist in the script, the error is "ENOEXEC".

The invoking program should then have a "default" implemented. By convention, command interpreters do have a default (several actually). Some just fork themselves and attempt to process the command. Others will take the value of environment variable "SHELL", and exec that combined with the script as a parameter. Yet others will do both - if the SHELL environment variable doesn't exist, then they will use a fork of themselves.

NOTE: bash, when it does this, only passes the exported symbol list, so the forked shell doing the processing does not have the nonexported symbols. I'm not sure about other shells, but I think this is the convention. It does make the environment of the script equivalent to that of a fork/exec sequence, even if the exec part is not done.

Now, as stated,this is only for those formats identified as "scripts". The kernel allows additional formats - the usual default is ELF, scripts, and java... All three examine the first couple of bytes to determine if they are applicable, then the system goes to the next one (and no, I'm not sure what the order is. I would think it would go ELF, Java, then scripts). It is also possible to have aout format, as well as other modules that get kernel modules loaded for support (one that handles java, em86, and wine, is binfmt_misc, but you have to have all the right options selected).
 
Old 04-18-2013, 10:31 AM   #24
David the H.
Bash Guru
 
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Debian sid + kde 3.5 & 4.4
Posts: 6,823

Rep: Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946Reputation: 1946
Quote:
Originally Posted by chrism01 View Post
As above, in fact I'd go with the even shorter version
Quote:
If you want to use the features of a specific shell features, your shebang needs to explicitly point to that interpreter.
and say always specify the shell you want, unless you are just messing about and know what your current shell really is/does.
See my previous post about PROD systems
Heh, I just noticed my typo. "Features of shell features", indeed.

And you're right, of course. The only reason to single out /bin/sh explicitly is the large amount of confusion surrounding it. The position it occupies in the OS is unclear to many, it's often conflated with other shells and, perhaps worst of all, non-posixly-defined features will usually continue to function with it if the underlying interpreter is compatible. It's one of the kings of gotchas.
 
Old 04-18-2013, 07:47 PM   #25
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,225

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
Quote:
It's one of the kings of gotchas
Yeah, I avoid it like the plague.
As you say, you never really know what you're actually(!) going to get....

On Linux I go bash, on Solaris, HP-UX etc, I usually go ksh; partly for historical reasons and partly because most others do on those platforms, so its simpler/kinder to stick to that.
Most of the built-ins in ksh work unaltered in bash, but the reverse is not true, as bash has continued to be developed, whereas the last official ksh release seems to be ksh93 http://kornshell.com/.

External cmds eg 'find' are a whole other bucket of fish
 
Old 04-21-2013, 08:22 PM   #26
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,481

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by chrism01 View Post
Most of the built-ins in ksh work unaltered in bash, but the reverse is not true, as bash has continued to be developed, whereas the last official ksh release seems to be ksh93 http://kornshell.com/.
Despite its name, ksh is still actively developed. Its last version is ksh93u+ (June 2012).

There are ksh93 specific features, bash specific features and occasionally differences in implementation so you need to stick with either POSIX compliant constructions or features implemented and supported the same way with bash and ksh to write scripts portable between both of these shells.

Last edited by jlliagre; 04-21-2013 at 08:36 PM. Reason: Link updated
 
Old 04-21-2013, 08:26 PM   #27
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,225

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
Interesting to know ksh is till being developed; thx.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
shebang -e argument Shwick Linux - Software 1 10-16-2008 09:54 PM
Help with shebang hammertime1983 Programming 11 11-06-2007 02:17 AM
Stuck on sript to scp a file nazs Programming 10 04-24-2007 06:19 PM
need shell backup sript maxut Linux - Software 2 10-12-2004 10:54 AM
execute sript? cloids Linux - Software 1 01-15-2004 01:03 PM


All times are GMT -5. The time now is 11:22 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration