Re: set -u not working as expected
> On Aug 2, 2020, at 2:51 AM, Oğuz wrote:
>
> `u' has no members, so there's nothing to expand. If you use `${u[0]}' for
> example, you'll see an error, I think how bash and ksh behave is perfectly
> reasonable.
Agreed. Their behavior logically follows from POSIX's carveout for $@.
>> % bash -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
>> bash: v: unbound variable
>> % ksh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
>> ksh: v: parameter not set
>> % zsh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
>> <0>
>>
>>
> `typeset -i v' doesn't assign `v', just gives it the integer attribute.
> Again, I can't see any problem with bash and ksh here.
Also agreed, but I was more interested in the next part...
>> % bash -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>> <1>
>> % ksh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>> <1>
>> % zsh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>> <1>
...which contrasts with the behavior of let. Someone else will have
to explain this, as I don't know what to make of it.
vq
Re: set -u not working as expected
2 Ağustos 2020 Pazar tarihinde Lawrence Velázquez yazdı:
> > On Aug 2, 2020, at 2:51 AM, Oğuz wrote:
> >
> > `u' has no members, so there's nothing to expand. If you use `${u[0]}'
> for
> > example, you'll see an error, I think how bash and ksh behave is
> perfectly
> > reasonable.
>
> Agreed. Their behavior logically follows from POSIX's carveout for $@.
>
> >> % bash -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
> >> bash: v: unbound variable
> >> % ksh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
> >> ksh: v: parameter not set
> >> % zsh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"'
> >> <0>
> >>
> >>
> > `typeset -i v' doesn't assign `v', just gives it the integer attribute.
> > Again, I can't see any problem with bash and ksh here.
>
> Also agreed, but I was more interested in the next part...
>
> >> % bash -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
> >> <1>
> >> % ksh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
> >> <1>
> >> % zsh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
> >> <1>
>
> ...which contrasts with the behavior of let. Someone else will have
> to explain this, as I don't know what to make of it.
>
>
Yeah, that's interesting. See this one:
$ set -u
$ unset foo bar
$ typeset -i foo bar
$
$ foo+=foo+1
$
$ foo+=bar+1
bash: bar: unbound variable
Only referencing `bar' triggers the _unbound variable_ error, it makes
sense that the name being assigned is immune to that.
Concerning `let v+=1', let is not a declaration utility, it's arguments are
arithmetic expressions to be evaluated. And in arithmetic evaluation
context:
> Shell variables are allowed as operands; parameter expansion
> is performed before the expression is evaluated.
> vq
--
Oğuz
Re: set -u not working as expected
However, > In arithmetic evaluation context, if a variable for which the integer attribute is set appears at the LHS of an assignment operator, it shouldn't be expanded. would be a reasonable feature request I guess. -- Oğuz
Re: bashbug's default editor
On 7/31/20 11:26 AM, Eli Schwartz wrote: >>> "If EDITOR is not set, bashbug attempts to locate a number of >>> alternative editors, including emacs, and defaults to vi." >>> >>> The word "defaults" there implies that vi is the preferred autolocated >>> editor, but the intention is to have it the least preferred. >> >> I don't think it implies that. It's the default choice if there are no >> other alternatives. > > In the sentence in the bashbug manpage, does the word "default" refer to > the probing or what happens when probing fails? > > My belief is that people reading the manpage will understand it to mean > the former (more natural reading). I don't think it's a more natural reading, but I'll rework the text to address the ambiguity. It's also reasonable to add `nano' to bashbug's list of editors. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: set -u not working as expected
On 8/1/20 2:48 PM, Kristof Burek wrote:
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> (Machine is a Raspberry Pi running Raspbian "Buster")
>
> Description:
> After set -u in a script: when x has not yet been bound to a value,
> I would expect the statements x+='x' and x+=('x') to cause Bash to
> report an error and exit the script. But it does not.
This does not fall under the `expand an unset parameter' scope where the
`-u' option is active.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: set -u not working as expected
On 8/1/20 8:47 PM, Lawrence Velázquez wrote:
>> let v+=1 # Line 18, Once line 11 is uncommented, Bash fails here
>
> I haven't seen the code for arithmetic expansion, but I assume it
> treats v+=1 as morally equivalent to v=${v}+1 (à la C99). Thus there
> *is* an expansion, which fails under set -u. Regardless of the
> particulars, ksh and zsh again agree:
This is indeed what happens in an arithmetic context. It happens with
pre- and post-increment and decrement operators, too.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: set -u not working as expected
On 8/2/20 3:34 AM, Lawrence Velázquez wrote: >>> % bash -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"' >>> <1> >>> % ksh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"' >>> <1> >>> % zsh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"' >>> <1> > > ...which contrasts with the behavior of let. Someone else will have > to explain this, as I don't know what to make of it. The integer attribute means the rhs of the assignment operator is evaluated as an expression. It doesn't mean the assignment is performed in an arithmetic context, as with `let' or `$((...))'. The special case, which is done to conform to user expections, is that the result is added to the current value, if any, instead of being appended like the usual behavior of `+='. Note that there are no corresponding `name*=value' or `name-=value' variable assignment operators, and that `-u' isn't in effect for any use of `+=', whether the integer attribute is present or not. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: set -u not working as expected
On 8/2/20 4:01 AM, Oğuz wrote: > $ set -u > $ unset foo bar > $ typeset -i foo bar > $ > $ foo+=foo+1 > $ > $ foo+=bar+1 > bash: bar: unbound variable > > Only referencing `bar' triggers the _unbound variable_ error, it makes > sense that the name being assigned is immune to that. You could make a decent case that this is a bug in bash, I suppose, but I am comfortable with the current behavior. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Issue with Bash
On 7/31/20 10:04 AM, Ayappan P2 wrote: > We are passing SIGHUP from another terminal ( not from the terminal which > has the interactive bash shell) . The terminal which has the interactive > bash closes immediately. > > The scenario is we just open two terminals. In one terminal , just invoke > bash . And from another terminal pass SIGHUP to the parent process (ksh) of > bash. That part is all fine, it's the fact that bash gets SIGHUP when it calls tcsetattr(), when SIGHUP isn't one of the signals that is documented as valid for tcsetattr(). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Issue with Bash
On 7/31/20 7:27 PM, Ángel wrote: > On 2020-07-31 at 10:13 -0400, Chet Ramey wrote: >> >> I'm going to have to test some more. When I tried it, all the shells >> died. >> (I did send the SIGHUP from another terminal.) I was using ksh93 as >> the parent and bash-5.0.18 as the interactive bash, running on macOS. > > This is probably AIX-specific in that some ioctl called by tcsetattr > seems to cause a SIGHUP when there is no tty. > Their behavior kinda make sense. Maybe, but it's not documented and seems to be unique to AIX. > Can probably be easily fixed by masking SIGHUP in the handler. It's a little more complicated to make that happen, but that's probably going to be the right approach (AIX-specific, of course). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Expand first before asking the question "Display all xxx possibilities?"
Instead of $ zz /jidanni_backups/da Display all 113 possibilities? (y or n) n and then finally showing $ zz /jidanni_backups/dan_home_bkp how about doing the expansion first, so entering $ zz /jidanni_backups/da would then change into $ zz /jidanni_backups/dan_home_bkp with below it the question Display all 113 possibilities? (y or n)
