Re: Tilde expansion during command search
On Wed, Jul 23, 2014 at 11:00 PM, lolilolicon wrote: > On Wed, Jul 23, 2014 at 10:43 PM, Eric Blake wrote: >> But we are talking about the case where ~ IS quoted during >> the assignment, and only bash then re-expands it during path lookup. > > That's my point. Let me try quoting this again, > > Note that the tildes are expanded during the assignment to PATH, _not > when PATH is accessed during command search._ > > in which I was trying to imply that, Bash *does* expand the tildes _when > PATH is accessed during command search._ I'm sorry if it felt like I was taking that sentence out of context. Well, I was; but I think it's fair to assume that whoever wrote that sentence would agree that tilde expansion should not be performed when PATH is accessed during command search. "If the tilde were escaped when the PATH were assigned, should we give the tilde a second chance and expand it when the PATH were accessed?" To which POSIX would probably say, "Hell no. We're reluctant enough to allow tilde expansion in assignments already!" How reluctant? If you look at the spec[1], you will see things like: Tilde expansion generally occurs only at the beginning of words, but an exception based on _historical practice_ has been included: and more directly Consideration was given to prohibiting this behaviour because any of the following are reasonable substitutes: So, has anyone asked the POSIX people about this? [1] http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_001
Re: leading zeros ignored by perl, ksh. not bash
On Wednesday, July 23, 2014 05:44:25 PM Dan Douglas wrote: > On Wednesday, July 23, 2014 05:02:42 PM Chet Ramey wrote: > > ksh93 -c 'echo $(( 010 ))' > > Oh heh. Maybe a compile-time option or something I'm doing wrong... I always > assumed it intentionally violates POSIX. > > I also just noticed zsh interprets it in bash and sh mode but not ksh or zsh > mode. (it's the very first difference I've ever noticed in zsh between bash > and ksh emulations.) Ah, I did do it wrong. $ ksh -c 'echo $((09))' 9 I interpreted the lack of error as not recognizing the 0. -- Dan Douglas
Re: leading zeros ignored by perl, ksh. not bash
On Wednesday, July 23, 2014 05:02:42 PM Chet Ramey wrote: > ksh93 -c 'echo $(( 010 ))' Oh heh. Maybe a compile-time option or something I'm doing wrong... I always assumed it intentionally violates POSIX. I also just noticed zsh interprets it in bash and sh mode but not ksh or zsh mode. (it's the very first difference I've ever noticed in zsh between bash and ksh emulations.) -- Dan Douglas
Re: leading zeros ignored by perl, ksh. not bash
On 7/23/14, 4:49 PM, Dan Douglas wrote: > I don't believe there are any cases in which ksh interprets a leading > zero, at least not current versions. If you want octal you must use > either 8#num or typeset -ibase. Same applies to both zsh and mksh > AFAICT. $ ksh93 -c 'echo $(( 010 ))' 8 Posix requires it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: leading zeros ignored by perl, ksh. not bash
On Wed, Jul 23, 2014 at 1:29 PM, Chet Ramey wrote: > On 7/23/14, 3:20 AM, maik.lied...@sungard.com wrote: >> hello, >> >> to change our scripts from ksh to bash we have problems with vars and >> leading zeros. >> how we can declare hrs and min? > > Greg offered several good suggestions to force base 10 in certain > situations. > >> or can we disable the automatic change from decimal to octal? > > No. Bash treats integer constants identically regardless of the context: a > leading 0 denotes octal. ksh93 treats constants with leading zeros > differently in different contexts (assigning to a variable with the integer > attribute set happens to be one of the cases where ksh93 treats a constant > as strictly decimal). I don't believe there are any cases in which ksh interprets a leading zero, at least not current versions. If you want octal you must use either 8#num or typeset -ibase. Same applies to both zsh and mksh AFAICT.
Re: leading zeros ignored by perl, ksh. not bash
On 7/23/14, 3:20 AM, maik.lied...@sungard.com wrote: > hello, > > to change our scripts from ksh to bash we have problems with vars and leading > zeros. > how we can declare hrs and min? Greg offered several good suggestions to force base 10 in certain situations. > or can we disable the automatic change from decimal to octal? No. Bash treats integer constants identically regardless of the context: a leading 0 denotes octal. ksh93 treats constants with leading zeros differently in different contexts (assigning to a variable with the integer attribute set happens to be one of the cases where ksh93 treats a constant as strictly decimal). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: leading zeros ignored by perl, ksh. not bash
On Wed, Jul 23, 2014 at 07:20:01AM +, maik.lied...@sungard.com wrote:
> how we can declare hrs and min?
> or can we disable the automatic change from decimal to octal?
Strip the leading zeroes, or force base 10 with 10#$foo inside the math
context.
> TIME="08:09"
Using all-caps variables is going to bite you in the ass one of these
days. The shorter and more common the variable name, the more likely
it will cause grief. All-caps variable names are generally reserved
for environment variables (HOME, PATH), or shell variables that alter
the shell's behavior or reveal internal state (CDPATH, RANDOM).
> hrs=$(echo ${TIME}|cut -f1 -d ':')
> min=$(echo ${TIME}|cut -f2 -d ':')
Here's a variant that strips the leading zero. This is my personal pick:
time="08:09"
hrs=${time:0:2} hrs=${hrs#0}
min=${time:3:2} min=${min#0}
echo "Total time elapsed $((hrs*60+min)) minutes"
Here's a variant that uses 10# to force base 10:
time="08:09"
hrs=${time:0:2}
min=${time:3:2}
echo "Total time elapsed $((10#$hrs*60 + 10#$min)) minutes"
> locmin=hrs*60+min
I also strongly discourage the use of "declare -i". It's very confusing.
If you want to do arithmetic, it's easier for the reader to understand
what's happening if you actually use arithmetic syntax, rather than
relying on the reader to remember that you used "declare -i" 600 lines
ago, or in a dotted-in script.
locmin=$((hrs*60+min))
leading zeros ignored by perl, ksh. not bash
hello,
to change our scripts from ksh to bash we have problems with vars and leading
zeros.
how we can declare hrs and min?
or can we disable the automatic change from decimal to octal?
leading zeros ignored by perl, ksh. not bash
cannnot declare vars hrs and min as decimal only
user@host:/home/user> ./mltest.pl
TIME = 08:09
hrs=08 | min=09 | locmin=489
user@host:/home/user> ./mltest.ksh
TIME=08:09
hrs=8 | min=9 | locmin=489
user@host:/home/user> ./mltest.sh
TIME=08:09
./mltest.sh: line 9: 08: value too great for base (error token is "08")
./mltest.sh: line 10: 09: value too great for base (error token is "09")
hrs= | min= | locmin=0
code (mltest.sh)
#!/bin/bash
declare -i hrs min locmin
TIME="08:09"
echo "TIME=$TIME"
hrs=$(echo ${TIME}|cut -f1 -d ':')
min=$(echo ${TIME}|cut -f2 -d ':')
#hrs=$(echo ${TIME}|cut -f1 -d ':'|bc -l) # workaround 1: ok
#min=$(echo ${TIME}|cut -f2 -d ':'|bc -l) # workaround 1: ok
###hrs=$(echo ${TIME}|cut -f1 -d ':'|sed "s/^0*//") # workaround 2: ok
###min=$(echo ${TIME}|cut -f2 -d ':'|sed "s/^0*//") # workaround 2: ok
locmin=hrs*60+min
echo "hrs=$hrs | min=$min | locmin=$locmin"
Kind regards / Cordialement / Mit freundlichen Grüssen
Maik Liedtke * System Consultant * ASP * Asset Arena * SunGard * Solmsstr. 18 *
60486 Frankfurt am Main, Deutschland
Tel +49 69 70768-118 * Mobile +49 176 0-118 * Fax +49 69 70768-599 *
mailto:maik.lied...@sungard.com *
www.sungard.com/assetarena
CONFIDENTIALITY: This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.
If you receive this e-mail in error, please notify the sender and delete this
e-mail from your system.
SunGard Systeme GmbH * Registered: Frankfurt am Main, Handelsregister Frankfurt
HRB 56839 * Geschäftsführer: Dean B. Gluyas, Christian U. Haas, Henry Morton
Miller Jr., Victoria E. Silbey
Re: Tilde expansion during command search
On Wed, Jul 23, 2014 at 10:43 PM, Eric Blake wrote: > But we are talking about the case where ~ IS quoted during > the assignment, and only bash then re-expands it during path lookup. That's my point. Let me try quoting this again, Note that the tildes are expanded during the assignment to PATH, _not when PATH is accessed during command search._ in which I was trying to imply that, Bash *does* expand the tildes _when PATH is accessed during command search._
Re: Tilde expansion during command search
On 07/23/2014 08:38 AM, Eric Blake wrote: > On 07/23/2014 08:08 AM, lolilolicon wrote: >> >From this page: http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html >> >> Note that the tildes are expanded during the assignment to PATH, not >> when PATH is accessed during command search. > > No, it wasn't. Re-read the original post: > > PATH=\~/tmpdir The reference you were quoting used this example: PATH=~hlj/bin:~dwc/bin:$PATH where ~ is unquoted in the assignment, and therefore expanded during the assignment. But we are talking about the case where ~ IS quoted during the assignment, and only bash then re-expands it during path lookup. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Tilde expansion during command search
On 07/23/2014 08:08 AM, lolilolicon wrote: > On Wed, Jul 23, 2014 at 9:58 PM, Eric Blake wrote: >> >> Might be worth asking the POSIX folks if it is allowed by POSIX. What >> do other shells do? > >>From this page: http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html > > Note that the tildes are expanded during the assignment to PATH, not > when PATH is accessed during command search. No, it wasn't. Re-read the original post: PATH=\~/tmpdir typeset -p PATH which produced this output: declare -x PATH="~/tmpdir" which proves that ~ was not expanded in the assignment to PATH, but only in the use of PATH. I'm strongly in favor of keeping bash's behavior when in bash mode, but for 'set -o posix', I worry that bash differing from other shells may mean bash is not compliant with POSIX. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Array name expansion in bash-4.3
On 7/22/14, 1:24 PM, Corentin Peuvrel wrote:
> Hello,
>
> I think I found a bug in bash-4.3.
>
> An example should be self-explanatory :
>
> bash-4.2 :
> $ arr=( idx1 idx2 )
> $ i=arr[1]
> $ echo ${!i}
> idx2
> $ echo ${!i/x/X}
> idX2
>
> bash-4.3 :
> $ arr=( idx1 idx2 )
> $ i=arr[1]
> $ echo ${!i}
> idx2
> $ echo ${!i/x/X}
> idX1
>
> If we use pattern substitution (or removing prefix/suffix pattern, ...)
> with an expansion of an array name which contain a non zero index, it will
> still use the index 0.
Thanks for the report. This is the result of the variable indirection
discarding the correct index. The attached patch should fix it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/subst.c 2014-06-03 09:32:44.0 -0400
--- subst.c 2014-07-23 09:58:19.0 -0400
***
*** 7369,7373
if (want_indir)
! tdesc = parameter_brace_expand_indir (name + 1, var_is_special, quoted, quoted_dollar_atp, contains_dollar_at);
else
tdesc = parameter_brace_expand_word (name, var_is_special, quoted, PF_IGNUNBOUND|(pflags&(PF_NOSPLIT2|PF_ASSIGNRHS)), &ind);
--- 7445,7455
if (want_indir)
! {
! tdesc = parameter_brace_expand_indir (name + 1, var_is_special, quoted, quoted_dollar_atp, contains_dollar_at);
! /* Turn off the W_ARRAYIND flag because there is no way for this function
! to return the index we're supposed to be using. */
! if (tdesc && tdesc->flags)
! tdesc->flags &= ~W_ARRAYIND;
! }
else
tdesc = parameter_brace_expand_word (name, var_is_special, quoted, PF_IGNUNBOUND|(pflags&(PF_NOSPLIT2|PF_ASSIGNRHS)), &ind);
Re: Tilde expansion during command search
On Wed, Jul 23, 2014 at 9:58 PM, Eric Blake wrote: > > Might be worth asking the POSIX folks if it is allowed by POSIX. What > do other shells do? >From this page: http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html Note that the tildes are expanded during the assignment to PATH, not when PATH is accessed during command search. (resent with proper CC)
Re: Tilde expansion during command search
On Wednesday, July 23, 2014 07:58:26 AM Eric Blake wrote:
> On 07/23/2014 07:51 AM, Dan Douglas wrote:
> > On Wednesday, July 23, 2014 09:28:02 AM you wrote:
> >> On 7/23/14, 8:22 AM, Dan Douglas wrote:
> >>> Hi, from this discussion:
> >>>
> >>> https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200
> >>>
> >>> I can't find any reference that says substituting a literal tilde in PATH
> >>> should occur during command search.
> >>
> >> Bash has always done this, even back to the pre-version 1 days, and I don't
> >> see any reason to change it now.
> >>
> >
> > The only concerns I can think of are inconsistency with programs that use
> > execvp(), or possibly double-expansion in the event of a user name or any
> > path
> > containing ~.
> >
> > You're probably right in that it's not super critical if it hasn't caused
> > problems so far.
>
> Might be worth asking the POSIX folks if it is allowed by POSIX. What
> do other shells do?
>
I tested it in the link from my first post. AFAICT Bash is the only one.
#!/bin/bash
printf '%s\n' '#!/bin/sh' 'echo test' >~/tmpdir/testscript
chmod u+x ~/tmpdir/testscript
s=(bash ksh mksh posh zsh dash bb jsh)
# Testing for parameter expansion.
for sh in "${s[@]}"; do
printf '%-4s %s\n' "${sh}:" "$("$sh" -c 'PATH=\${HOME}/tmpdir; testscript'
2>&1)"
done
echo
# Testing for tilde expansion.
for sh in "${s[@]}"; do
printf '%-4s %s\n' "${sh}:" "$("$sh" -c 'PATH=\~/tmpdir; testscript' 2>&1)"
done
bash: bash: testscript: command not found
ksh: ksh: testscript: not found
mksh: mksh: testscript: not found
posh: posh: testscript: not found
zsh: zsh:1: command not found: testscript
dash: dash: 1: testscript: not found
bb: bb: testscript: not found
jsh: jsh: testscript: not found
bash: test
ksh: ksh: testscript: not found
mksh: mksh: testscript: not found
posh: posh: testscript: not found
zsh: zsh:1: command not found: testscript
dash: dash: 1: testscript: not found
bb: bb: testscript: not found
jsh: jsh: testscript: not found
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: Tilde expansion during command search
On 07/23/2014 07:51 AM, Dan Douglas wrote: > On Wednesday, July 23, 2014 09:28:02 AM you wrote: >> On 7/23/14, 8:22 AM, Dan Douglas wrote: >>> Hi, from this discussion: >>> >>> https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 >>> >>> I can't find any reference that says substituting a literal tilde in PATH >>> should occur during command search. >> >> Bash has always done this, even back to the pre-version 1 days, and I don't >> see any reason to change it now. >> > > The only concerns I can think of are inconsistency with programs that use > execvp(), or possibly double-expansion in the event of a user name or any > path > containing ~. > > You're probably right in that it's not super critical if it hasn't caused > problems so far. Might be worth asking the POSIX folks if it is allowed by POSIX. What do other shells do? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Tilde expansion during command search
On Wednesday, July 23, 2014 09:28:02 AM you wrote: > On 7/23/14, 8:22 AM, Dan Douglas wrote: > > Hi, from this discussion: > > > > https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 > > > > I can't find any reference that says substituting a literal tilde in PATH > > should occur during command search. > > Bash has always done this, even back to the pre-version 1 days, and I don't > see any reason to change it now. > The only concerns I can think of are inconsistency with programs that use execvp(), or possibly double-expansion in the event of a user name or any path containing ~. You're probably right in that it's not super critical if it hasn't caused problems so far. -- Dan Douglas
Re: Tilde expansion during command search
On 7/23/14, 8:22 AM, Dan Douglas wrote: > Hi, from this discussion: > > https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 > > I can't find any reference that says substituting a literal tilde in PATH > should occur during command search. Bash has always done this, even back to the pre-version 1 days, and I don't see any reason to change it now. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Tilde expansion during command search
Hi, from this discussion:
https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200
I can't find any reference that says substituting a literal tilde in PATH
should occur during command search.
$ ( cd ~
mkdir tmpdir
echo $'#!/bin/sh\necho "Hello from ${BASH_SOURCE}!"' >~/tmpdir/testscript
chmod u+x ~/tmpdir/testscript
PATH=\~/tmpdir
typeset -p PATH
testscript )
declare -x PATH="~/tmpdir"
Hello from /home/devtest/tmpdir/testscript!
$ echo "$BASH_VERSION"
4.3.18(1)-release
--
Dan Douglas
