a "script-relative" version of env
Hi all, This is not a bash bug, but I am hoping the people on this list would find the question interesting... I have found it useful to have a "script-relative" version of /usr/bin/env. Whereas env determines an interpreter's location based on PATH, this version would determine the interpreter's location based on the location of the script. Example - the shebang line: #!/usr/bin/relexec ../bin/perl would execute the interpreter ../bin/perl relative to the location of the script. The argv array of relexec will be: argv[0] = "/usr/bin/relexec" argv[1] = "../bin/perl" argv[2] = "/some/path/to/script" In this case relexec would exec /some/path/to/bin/perl with the arguments in argv starting from argv[2]. If anyone is interested I can explain why/how I use this. Questions: - Does something like this already exist? - I've noticed that the argument passed to the she-bang interpreter always seems to be an absolute path when commands are executed from a shell. Are there cases where that will not be true?
Re: a "script-relative" version of env
E R wrote: > - I've noticed that the argument passed to the she-bang interpreter > always seems to be an absolute path when commands are executed from a > shell. Are there cases where that will not be true? You might find reading Sven Mascheck's documentation interesting: http://www.in-ulm.de/~mascheck/various/shebang/ Bob
last argument expansion has different output using the sh interpreter
I tried to send this using bash-bug, however I didn't realize my sendmail
was not setup, so here is the description in the format of bash-bug.
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
When executing a test script using the #!/bin/sh interpreter line
the shell expansion for the last argument ${!#} is blank,
however when using #!/bin/bash the behavior is as expected. In this
setup /bin/sh is a link to /bin/bash.
Repeat-By:
Using the following test script:
#!/bin/sh
FIRSTARG=$1
FINALARG=${!#}
echo $FIRSTARG
echo $FINALARG
Output using #!/bin/sh
[hickersonj@fedora15 ~]$ ./test.sh first last
first
Output using #!/bin/bash
[hickersonj@fedora15 ~]$ ./test.sh first last
first
last
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-DRECYCLES_PIDS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables
uname output: Linux fedora15.localdomain 2.6.38.6-27.fc15.i686 #1 SMP Sun
May 15 17:57:13 UTC 2011 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Thanks,
Jacoby
Re: last argument expansion has different output using the sh interpreter
On Fri, May 27, 2011 at 12:35:12PM -0700, Jacoby Hickerson wrote:
> When executing a test script using the #!/bin/sh interpreter line
> the shell expansion for the last argument ${!#} is blank,
Good. And now you know why you use a proper #!/bin/bash shebang when
you use bash extensions in your script.
If you are using #!/bin/sh then you should use only POSIX sh features.
Re: last argument expansion has different output using the sh interpreter
On Fri, May 27, 2011 at 3:45 PM, Greg Wooledge wrote:
> On Fri, May 27, 2011 at 12:35:12PM -0700, Jacoby Hickerson wrote:
> > When executing a test script using the #!/bin/sh interpreter line
> > the shell expansion for the last argument ${!#} is blank,
>
> Good. And now you know why you use a proper #!/bin/bash shebang when
> you use bash extensions in your script.
>
> If you are using #!/bin/sh then you should use only POSIX sh features.
>
>
Indeed, indirection is a bash feature. I wouldn't expect it to work in
POSIX sh.
The only way I can think of to get the last argument in sh is to loop
through them,
something like:
for arg; do last="$arg"; done; echo "$last"
Re: last argument expansion has different output using the sh interpreter
On Fri, May 27, 2011 at 1:20 PM, DJ Mills wrote:
>
>
> On Fri, May 27, 2011 at 3:45 PM, Greg Wooledge wrote:
>
>> On Fri, May 27, 2011 at 12:35:12PM -0700, Jacoby Hickerson wrote:
>> > When executing a test script using the #!/bin/sh interpreter
>> line
>> > the shell expansion for the last argument ${!#} is blank,
>>
>> Good. And now you know why you use a proper #!/bin/bash shebang when
>> you use bash extensions in your script.
>>
>> If you are using #!/bin/sh then you should use only POSIX sh features.
>>
>>
> Indeed, indirection is a bash feature. I wouldn't expect it to work in
> POSIX sh.
>
> The only way I can think of to get the last argument in sh is to loop
> through them,
> something like:
> for arg; do last="$arg"; done; echo "$last"
>
Ah I see that inderection is a bash specific feature, in general I should
update all my scripts. Although, I am curious, is this is a matter of sh
being continually updated to exclude all bash extensions or perhaps
previously bash didn't interpret #!/bin/sh to be the POSIX compliant
interpreter?
Re: last argument expansion has different output using the sh interpreter
DJ Mills writes:
> The only way I can think of to get the last argument in sh is to loop
> through them,
> something like:
> for arg; do last="$arg"; done; echo "$last"
$ eval echo \"\${$#}\"
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: last argument expansion has different output using the sh interpreter
On Fri, May 27, 2011 at 01:35:50PM -0700, Jacoby Hickerson wrote: > Although, I am curious, is this is a matter of sh > being continually updated to exclude all bash extensions Eh? POSIX is defined by a group of people and published. Here's the current edition: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html "... continually updated to exclude bash extensions..." doesn't even make sense to me. It doesn't generally get *smaller* with each edition; rather, it gets larger. > or perhaps > previously bash didn't interpret #!/bin/sh to be the POSIX compliant > interpreter? Are you talking specifically about the behavior of bash when it is invoked as "sh"? If I were you, I wouldn't even waste brain cycles on that. When you write a script, decide whether you are writing a bash script, or an sh script. If you are writing a bash script, pick which version of bash you are writing it for, and then use the features available in that version and older, and use the #!/usr/bin/env bash or #!/bin/bash shebang. If you are writing for sh, then use only POSIX features, and use the #!/bin/sh shebang.
Re: last argument expansion has different output using the sh interpreter
Jacoby Hickerson wrote: > Although, I am curious, is this is a matter of sh being continually > updated to exclude all bash extensions or perhaps previously bash > didn't interpret #!/bin/sh to be the POSIX compliant interpreter? When bash is invoked as sh then bash complies with the POSIX sh. That is both required and desired. On some GNU/Linux systems /bin/sh is a symlink to /bin/bash and bash will support running as a POSIX sh. But this isn't universal. On other systems /bin/sh is an actual native POSIX sh, on others it is a symlink to /bin/ksh or /bin/zsh or /bin/dash or others. But in all cases /bin/sh is supposed to be a POSIX sh and conform to the standard. Bash tries to be compliant but some differences will creep in regardless. Doing so may cause problems for people who unknowingly use features on one system that are not available on other systems. Generally the wisdom of years is not to be generous in what you accept but to be strict in what you accept. It makes portability easier. Having found that the bash specific feature isn't available in /bin/sh this is a good thing for you since now your script will either need to specify that it needs bash explicitly or you could use portable only constructs and continue to use /bin/sh. Personally I use bash for my command line but /bin/sh and portable constructs for shell scripts. Bob
Re: edit-and-execute-command is appropriately named, weird
Hi Chet,
Thank you for the response, and the attempt at assistance.
I was unaware of the POSIX specifications relating to editing modes.
After reading the specs, however, I don't think they conflict with
what I propose. While the description of the [count]v command does
say that it executes the commands in the temporary file, this cannot
be required to apply to line editing in the read builtin when run with
the -e option, as the -e option is not described in the specification
of read at all and so its behavior is up to the developers here to
define.
Note that I am not proposing "edit and keep in buffer" semantics (as
you provided an example of below, and which would clearly conflict
with the standard), but rather "edit and accept" which results in
conformant behavior at the command prompt when the accepted line is
then processed as a shell command.
In the short term, I was able to get the behavior I want by overriding
fc in the script in question, but I still think default behavior is
ugly.
Thanks again for the response, and I'm interested in your further thoughts.
- David
On Thu, May 26, 2011 at 9:09 AM, Chet Ramey wrote:
> On 5/23/11 1:05 PM, David Thomas wrote:
>> Hi all,
>>
>> In using bash over the years, I've been quite happy to be able to hit
>> ctrl-x ctrl-e to pull up an editor when my input has grown too
>> complicated.
>>
>> When using read -e for input, however, the behavior I find makes a lot
>> less sense: the input line is still opened in an editor, but the
>> result is not processed by read - it is executed by bash. While a
>> means to escape to the shell can certainly be useful it seems like it
>> should generally be done in a more controlled environment. It is much
>> harder to reason about my scripts when arbitrary variables might be
>> overwritten just because I asked for input. In any case I'm not sure
>> it makes sense to conflate this with the "open this line in an editor"
>> command.
>
> That editing command exists because Posix standardizes it for vi editing
> mode. (Posix declined to standardize emacs editing mode at all.) It was
> useful to expose the same behavior when in emacs mode.
>
> If you want an `edit-in-editor' command that just replaces the readline
> editing buffer with the edited result, you should be able to write a shell
> function to do that and use `bind -x' to make it available on any key
> sequence you want (modulo the current restrictions on bind -x, of course).
>
> Something like this:
>
> edit_in_editor()
> {
> typeset p
> local TMPF=/tmp/readline-buffer
>
> p=$(READLINE_POINT}
> rm -f $TMPF
> printf "%s\n" "$READLINE_LINE" > "$TMPF"
> ${VISUAL:-${EDITOR:-emacs}} $TMPF && READLINE_LINE=$(< $TMPF)
> rm -f $TMPF
> READLINE_POINT=0 # or p or ${#READLINE_LINE} or ...
> }
>
> Salt to taste.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
>
Re: last argument expansion has different output using the sh interpreter
On Fri, 2011-05-27 at 16:53 -0400, Greg Wooledge wrote: > On Fri, May 27, 2011 at 01:35:50PM -0700, Jacoby Hickerson wrote: > > Although, I am curious, is this is a matter of sh > > being continually updated to exclude all bash extensions > > Eh? POSIX is defined by a group of people and published. Here's the > current edition: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html > > "... continually updated to exclude bash extensions..." doesn't even make > sense to me. It doesn't generally get *smaller* with each edition; > rather, it gets larger. A simpler question that I could have asked would be "Why did it work before?" The now obvious answer is that it shouldn't have worked before. I just didn't know how sh evolves, now it is much more clear thanks. > > or perhaps > > previously bash didn't interpret #!/bin/sh to be the POSIX compliant > > interpreter? > > Are you talking specifically about the behavior of bash when it is invoked > as "sh"? If I were you, I wouldn't even waste brain cycles on that. > When you write a script, decide whether you are writing a bash script, > or an sh script. If you are writing a bash script, pick which version of > bash you are writing it for, and then use the features available in that > version and older, and use the #!/usr/bin/env bash or #!/bin/bash shebang. > If you are writing for sh, then use only POSIX features, and use the > #!/bin/sh shebang. It was being executed from within a bash shell but using #!/bin/sh shebang inside the script. I understand that the shebang will call out the desired interpreter i.e. #!/usr/bin/perl, I was simply mistaken in thinking that sh was equivalent to bash.
Re: last argument expansion has different output using the sh interpreter
On Fri, 2011-05-27 at 14:57 -0600, Bob Proulx wrote: > Jacoby Hickerson wrote: > > Although, I am curious, is this is a matter of sh being continually > > updated to exclude all bash extensions or perhaps previously bash > > didn't interpret #!/bin/sh to be the POSIX compliant interpreter? > > When bash is invoked as sh then bash complies with the POSIX sh. That > is both required and desired. > > On some GNU/Linux systems /bin/sh is a symlink to /bin/bash and bash > will support running as a POSIX sh. But this isn't universal. On > other systems /bin/sh is an actual native POSIX sh, on others it is a > symlink to /bin/ksh or /bin/zsh or /bin/dash or others. But in all > cases /bin/sh is supposed to be a POSIX sh and conform to the > standard. Bash tries to be compliant but some differences will creep > in regardless. Doing so may cause problems for people who unknowingly > use features on one system that are not available on other systems. > Generally the wisdom of years is not to be generous in what you accept > but to be strict in what you accept. It makes portability easier. > > Having found that the bash specific feature isn't available in /bin/sh > this is a good thing for you since now your script will either need to > specify that it needs bash explicitly or you could use portable only > constructs and continue to use /bin/sh. Personally I use bash for my > command line but /bin/sh and portable constructs for shell scripts. > > Bob > Yes in this environment it is a link. It certainly makes sense to write it in a POSIX compliant way in order to be portable, but some extended features of bash make life easier. Since this was an upgrade from a previous distro Fedora 14 -> Fedora 15, I didn't think portability with a shell script would be an issue, but now it is much more clear after I have been bitten :). Your response is very excellent information and thanks to you all for the wealth of data. Thanks! Jacoby
