Re: Behaviour of eval in sh(1) and ksh(1) in AND-OR list with set -e
On 2019-06-05, Andreas Kusalananda Kähäri wrote: > When running under set -e, why does > eval false || echo ok > terminate the script with the execution of eval? I think that's a bug. > then why does the below behave differently? > eval ! true || echo ok That's actually the documented, POSIX-specified behavior. Somewhat bizarrely, ! disables errexit. The eval doesn't matter here. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Behaviour of eval in sh(1) and ksh(1) in AND-OR list with set -e
On Wed, Jun 05, 2019 at 08:05:48PM +0200, Andreas Kusalananda Kähäri wrote: > When running under set -e, why does > > eval false || echo ok Just to clarify: OpenBSD's sh(1) and ksh(1) make it impossible to run code like set -e if eval "$string"; then echo ok else echo not ok fi where "$string" is a piece of code that returns a non-zero exit status. This script would not output anything with string=false, for example, even though the eval occurs as a test within a conditional statement. > > terminate the script with the execution of eval? As far as I know, the > OpenBSD sh(1) and ksh(1) shells are the only ones doing that. > > If we take termination of the script as a given in the above scenario > (even if it feel a bit odd since it's in an AND-OR list), then why does > the below behave differently? > > eval ! true || echo ok > > This would not terminate the shell regardless of set -e or not. > > Is that a bug or is it a different interpretation of the standard? > > > > -- > Kusalananda > Sweden -- Kusalananda Sweden
Behaviour of eval in sh(1) and ksh(1) in AND-OR list with set -e
When running under set -e, why does eval false || echo ok terminate the script with the execution of eval? As far as I know, the OpenBSD sh(1) and ksh(1) shells are the only ones doing that. If we take termination of the script as a given in the above scenario (even if it feel a bit odd since it's in an AND-OR list), then why does the below behave differently? eval ! true || echo ok This would not terminate the shell regardless of set -e or not. Is that a bug or is it a different interpretation of the standard? -- Kusalananda Sweden
Re: sh(1), ksh(1) - lack of information about default sourcefile.
Hi, Black Rider wrote on Sun, Jun 14, 2015 at 02:48:17PM +: I have noticed that the ksh and sh manpages don't make reference to the file /.profile, which I understand to hold the default shell variables if the other source files listed on the manuals don't exist. Sorry for being late to the party, but as nobody clarified, better late than never. The .profile file in the root directory isn't used when other initialization *files* don't exist, but it is used in place of ~/.profile when the $HOME *directory* does not exist. That's an obscure corner case that i don't think needs to be documented. Besides, it's not even really specific to the shell. It more about login(1). If your home dir doesn't exist, you get HOME=/ - and that's about all there is to it. Yours, Ingo
Re: sh(1), ksh(1) - lack of information about default sourcefile.
El Sun, 14 Jun 2015 16:19:58 +0100, Maurice McCarthy escribió: The file itself says it is for default for root. My bad, that is true. An user here had noticed that some shell variables existed in his shell even if no /etc/profile nor ~/.profile (nor other files listed in sh(1) and ksh(1)) existed. We wondered where the defaults came from and we only could find the /.profile file (which, as you have pointed, is not the source of these variables). Some further investigation suggest these variables could come from /etc/ login.conf.
Re: sh(1), ksh(1) - lack of information about default sourcefile.
On Sun, Jun 14, 2015 at 02:48:17PM + or thereabouts, Black Rider wrote:
Hello.
I have noticed that the ksh and sh manpages don't make reference to the
file /.profile, which I understand to hold the default shell variables if
the other source files listed on the manuals don't exist.
The file itself says it is for default for root.
$ cat /.profile
# $OpenBSD: dot.profile,v 1.9 2010/12/13 12:54:31 millert Exp $
#
# sh/ksh initialization
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
export PATH
: ${HOME='/root'}
export HOME
umask 022
case $- in
*i*)# interactive shell
if [ -x /usr/bin/tset ]; then
if [ X$XTERM_VERSION = X ]; then
eval `/usr/bin/tset -sQ '-munknown:?vt220' $TERM`
else
eval `/usr/bin/tset -IsQ '-munknown:?vt220' $TERM`
fi
fi
;;
esac
Re: [[ in sh(1)
On 7/17/07, Paul de Weerd [EMAIL PROTECTED] wrote: On Tue, Jul 17, 2007 at 11:42:14AM -0400, Eric Furman wrote: | The description of [[ ]] is missing from sh(1) though, hence my | statement which, I believe, is only a difference in documentation. | This difference is only in the documentation. The following two constructs behave the same in /bin/sh and /bin/ksh : [[ foobar = f*r ]] echo YES || echo NO [ foobar = f*r ] echo YES || echo NO At least, they do when I just tried : That's because in OpenBSD they are the same binary.. -Nick
[[ in sh(1)
hi there, i have found a script on hp-ux that uses [[ ]] instead of the if [ ]; then construct so i went to sh(1), and while [[ is listed as a compound command, i couldn't find any explanation of what it does and how is it different if at all. could the doc experts advise please and update the docs? -f -- always remember that you are unique. just like everyone else.
Re: [[ in sh(1)
On 2007/07/17 15:42, frantisek holop wrote: so i went to sh(1), and while [[ is listed see ksh(1)
Re: [[ in sh(1)
On Tue, Jul 17, 2007 at 03:42:53PM +0200, frantisek holop wrote: | i have found a script on hp-ux that uses | [[ ]] instead of the if [ ]; then construct | so i went to sh(1), and while [[ is listed | as a compound command, i couldn't find any | explanation of what it does and how is it | different if at all. | | could the doc experts advise please and | update the docs? My manpage (ksh(1)) says : [[ expression ]] Similar to the test and [ ... ] commands (described later), with the following exceptions: And then lists some exceptions. This could be a difference between sh and ksh (which, I believe, is only a difference in documentation). Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: [[ in sh(1)
On 2007/07/17 16:07, Paul de Weerd wrote: On Tue, Jul 17, 2007 at 03:42:53PM +0200, frantisek holop wrote: | i have found a script on hp-ux that uses | [[ ]] instead of the if [ ]; then construct | so i went to sh(1), and while [[ is listed | as a compound command, i couldn't find any | explanation of what it does and how is it | different if at all. | | could the doc experts advise please and | update the docs? My manpage (ksh(1)) says : [[ expression ]] Similar to the test and [ ... ] commands (described later), with the following exceptions: And then lists some exceptions. This could be a difference between sh and ksh (which, I believe, is only a difference in documentation). It does different things depending on whether it's run as ksh or sh.
Re: [[ in sh(1)
On Tue, Jul 17, 2007 at 03:27:51PM +0100, Stuart Henderson wrote: | My manpage (ksh(1)) says : | | [[ expression ]] | Similar to the test and [ ... ] commands (described later), with | the following exceptions: | | And then lists some exceptions. This could be a difference between sh | and ksh (which, I believe, is only a difference in documentation). | | It does different things depending on whether it's run as ksh or sh. As far as my quick test (not definitive by any means) shows, it does not do anything different with respect to handling [[ ]]. The description of [[ ]] is missing from sh(1) though, hence my statement which, I believe, is only a difference in documentation. Sorry for the confusion. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: [[ in sh(1)
On Tue, 17 Jul 2007 16:35:03 +0200, Paul de Weerd [EMAIL PROTECTED] said: On Tue, Jul 17, 2007 at 03:27:51PM +0100, Stuart Henderson wrote: | My manpage (ksh(1)) says : | | [[ expression ]] | Similar to the test and [ ... ] commands (described later), with | the following exceptions: | | And then lists some exceptions. This could be a difference between sh | and ksh (which, I believe, is only a difference in documentation). | | It does different things depending on whether it's run as ksh or sh. As far as my quick test (not definitive by any means) shows, it does not do anything different with respect to handling [[ ]]. The description of [[ ]] is missing from sh(1) though, hence my statement which, I believe, is only a difference in documentation. [[ is not listed in sh(1) because this construct doesn't exist in sh(1). There is a difference in the [[ construct in ksh. Read man ksh(1). Most significantly; o Field splitting and file name generation are not per- formed on arguments. o The second operand of the `!=' and `=' expressions are patterns (e.g. the comparison [[ foobar = f*r ]] suc- ceeds).
Re: [[ in sh(1)
On Tue, Jul 17, 2007 at 11:42:14AM -0400, Eric Furman wrote: | | And then lists some exceptions. This could be a difference between sh | | and ksh (which, I believe, is only a difference in documentation). | | | | It does different things depending on whether it's run as ksh or sh. | | As far as my quick test (not definitive by any means) shows, it does | not do anything different with respect to handling [[ ]]. | | The description of [[ ]] is missing from sh(1) though, hence my | statement which, I believe, is only a difference in documentation. | | [[ is not listed in sh(1) because this construct doesn't exist in sh(1). | There is a difference in the [[ construct in ksh. Read man ksh(1). | Most significantly; | o Field splitting and file name generation are not per- | formed on arguments. | o The second operand of the `!=' and `=' expressions are | patterns (e.g. the comparison [[ foobar = f*r ]] suc- | ceeds). This difference is only in the documentation. The following two constructs behave the same in /bin/sh and /bin/ksh : [[ foobar = f*r ]] echo YES || echo NO [ foobar = f*r ] echo YES || echo NO At least, they do when I just tried : $ echo $SHELL /bin/ksh $ [[ foobar = f*r ]] echo YES || echo NO YES $ [ foobar = f*r ] echo YES || echo NO NO $ chsh -s /bin/sh logout, login $ echo $SHELL /bin/sh $ [[ foobar = f*r ]] echo YES || echo NO YES $ [ foobar = f*r ] echo YES || echo NO NO I see very little differnece. Like I said, only in the documentation. And I do believe this has been discussed on this list before ;) Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: [[ in sh(1)
hmm, on Tue, Jul 17, 2007 at 11:42:14AM -0400, Eric Furman said that [[ is not listed in sh(1) because this construct doesn't exist in sh(1). There is a difference in the [[ construct in ksh. Read man ksh(1). right, thanks for the answers. but is it supposed to be listed in sh(1) or not at all? i mean if listed, it could get at least a sentence that it's the same as [ ] or not the same, whatever, no? also, is this posix? becasuse the hp-ux posix-sh(1) (or was it sh-posix(1)?) shell happily processes it... -f -- a fool searches for a greater fool to find admiration.
Re: [[ in sh(1)
On 2007/07/17 19:37, frantisek holop wrote: hmm, on Tue, Jul 17, 2007 at 11:42:14AM -0400, Eric Furman said that [[ is not listed in sh(1) because this construct doesn't exist in sh(1). There is a difference in the [[ construct in ksh. Read man ksh(1). right, thanks for the answers. but is it supposed to be listed in sh(1) or not at all? i mean if listed, it could get at least a sentence that it's the same as [ ] or not the same, whatever, no? also, is this posix? becasuse the hp-ux posix-sh(1) (or was it sh-posix(1)?) shell happily processes it... SUS says it's undefined behaviour, don't use it in portable scripts.
