Re: "Variation" in Command Substitution Behaviour
Hi Reuti, Andreas,
Yes, forgot to mention the bash versions I have tried: 4.3.46 on Arch Linux
and 4.1.2 on CentOS 6.8.
This is getting weirder: I've found I can replicate the behaviour you are
getting Reuti, if I first do this command:
unset COMMAND_PROMPT
If I want to go back to the behaviour I first experienced (i.e.
Rubbles=barney after running assemble_fam1 then assemble_fam2), then I put
the default COMMAND_PROMPT back:
PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}"
"${PWD/#$HOME/~}"'
Does this work the same for you?
Geoff
On 1 March 2017 at 02:21, Reuti wrote:
> Hi,
>
> > Am 28.02.2017 um 11:00 schrieb Andreas Schwab :
> >
> > On Feb 28 2017, Geoff Hull wrote:
> >
> >> If I "source" the attached file (i.e. ". test_aliases") in a bash
> session,
> >> then run the following:
> >>
> >> assemble_fam1
> >> assemble_fam2
> >> say_families
> >>
> >> I see the following output:
> >>
> >> Flintstones=wilma:bam-bam:fred
> >> Rubbles=barney
>
> In which version of Bash are you observing this? For me it's working using
> this order, but when I swap assemble_fam1 and assemble_fam2 I observe a
> strange behavior, that RUBBLES gets reset and I get your output:
>
> $ assemble_fam1
> $ assemble_fam2
> $ say_families
> Flintstones=wilma:bam-bam:fred
> Rubbles=betty:pebbles:barney
> $ reset_vars
> $ assemble_fam2
> $ say_families
> Flintstones=
> Rubbles=betty:pebbles:barney
> $ assemble_fam1
> $ say_families
> Flintstones=wilma:bam-bam:fred
> Rubbles=barney
>
>
> This I have in 4.2 and 4.4.
>
> $ reset_vars
> + reset_vars
> + unset FSTONES RUBBLES
> $ assemble_fam2
> + barney
> ++ echo barney
> + RUBBLES=barney
> $ say_families
> + RUBBLES=betty:pebbles:barney
> + say_families
> + echo Flintstones=
> Flintstones=
> + echo Rubbles=betty:pebbles:barney
> Rubbles=betty:pebbles:barney
> $ assemble_fam1
> + fred
> ++ echo fred
> + FSTONES=fred
> + FSTONES=wilma:bam-bam:fred
> $ say_families
> + say_families
> + echo Flintstones=wilma:bam-bam:fred
> Flintstones=wilma:bam-bam:fred
> + echo Rubbles=barney
> Rubbles=barney
>
>
> > It seems like the shell is eating an extra newline. Try typing an empty
> > line after assemble_fam2:
>
> The extra newline doesn't help for the observation above. While defining
> assemble_famX in one line for both does as mentioned by Geoff.
>
> -- Reuti
>
Re: break no longer breaks out of loops defined in an outer context
On 2/28/17 3:10 PM, Stephane Chazelas wrote: > There was a related discussion on the Austin group mailing list > back in May last year: > > http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12614 > > Just my personal opinion, but I think I'd rather the spec had > been updated to accomodate the bash (and many other shells) > behaviour rather than bash breaking its backward compatibility > to comply to a requirement that is not particularly useful > myself. That's why I made the bash-4.3 behavior available via the shell compatibility level mechanism. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: break no longer breaks out of loops defined in an outer context (was: Bug????)
2017-02-28 19:43:11 +0100, tarot: > Gr! it is not a bug!!! > > > xx. Fixed a bug that could allow `break' or `continue' executed from shell > functions to affect loops running outside of the function. > > My BIG script doesn't work with bash-4.4 > There was a related discussion on the Austin group mailing list back in May last year: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12614 Just my personal opinion, but I think I'd rather the spec had been updated to accomodate the bash (and many other shells) behaviour rather than bash breaking its backward compatibility to comply to a requirement that is not particularly useful myself. You'll find more at that thread, though with the gmane web interface not fully back up, it's hard to get the whole thread (you can increase that 12614 number above). -- Stephane
Re: Bug ???????????
On 2/28/17 1:43 PM, tarot wrote: > Gr! it is not a bug!!! It is a bug, but if you rely on the previous behavior, you can set your shell's compatibility level to 4.3 (BASH_COMPAT=4.3) and get the behavior you want. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bug ???????????
Gr! it is not a bug!!! xx. Fixed a bug that could allow `break' or `continue' executed from shell functions to affect loops running outside of the function. My BIG script doesn't work with bash-4.4
semicolon not added to history items when final line of compound list ends with a comment
Usually a multi-line command gets added to the history list with
semicolons added in the requisite places, i.e:
$ f() {
> :
> }
$ fc -ln -1
f() { :; }
However, if the final line is a comment, the semicolon is not added,
making the history item an invalid command:
$ f() {
> :
> #
> }
$ fc -ln -1
f() { : }
Similarly, if the final line is a command which ends in a comment, the
comment character is preserved as part of the command, again making
the resulting history item invalid:
$ f() {
> : #
> }
$ fc -ln -1
f() { : #; }
Same is true for `for' and `while' loops, `if` and `select' statements, etc.
Re: Why two separate option namespaces?
2017-02-27 16:18:46 -0500, Chet Ramey: > On 2/27/17 11:50 AM, Martijn Dekker wrote: > > > So basically you're saying that, for options without a single-letter > > equivalent, "-o" options are those that are either POSIX or that you > > think should be POSIX? But then that distinction is more political than > > technical, isn't it? > > Heh. Let's just say that I'm leaving the `set -o' namespace to Posix. [...] Well, not really since bash already has extensions over the POSIX ones. Note that all of ksh, yash and zsh at least have extensions of their own there. bash seems to be the last actively maintained POSIX-certified shell, so I don't expect POSIX would come up with option names that would conflict with bash's, so from that point of view, it would be safe to merge the name spaces. It may be worth checking other shell implementations to see if there are potential conflicts. Uniformizing between all shells would help writing scripts portable across several of the modern Bourne-like shells. zsh and yash are being conciliatory there in that they ignore case, underscore (even hyphen for yash) and treat a "no" prefix as inverting the setting. yash and zsh also accept -- to "set" and to the interpreter (in the case of yash, a la GNU, that is accepting unambiguous abbreviations like set --posix for set --posixlycorrect). bash also accepts -- (but does not support GNU-like abbreviations) for a restricted set of options like verbose/posix. See also bash --restricted vs bash -O restricted_shell (the latter one being ineffective). (that's another set of "options" that may be worth merging). So bash's shopt -s nocasematch also works as set -o nocasematch in those shells (in addition to set +o CASE_MATCH for instance). and bash's set -o posix also works (though with different effect even if the intention is the same) in zsh and yash (even if posix is not a valid option name in yash). There are things like bash.extglob vs zsh.kshglob (zsh also has zsh.extendedglob for its own extended globs) -- Stephane
Re: "Variation" in Command Substitution Behaviour
> Am 28.02.2017 um 14:21 schrieb Reuti : > > Hi, > >> Am 28.02.2017 um 11:00 schrieb Andreas Schwab : >> >> On Feb 28 2017, Geoff Hull wrote: >> >>> If I "source" the attached file (i.e. ". test_aliases") in a bash session, >>> then run the following: >>> >>> assemble_fam1 >>> assemble_fam2 >>> say_families >>> >>> I see the following output: >>> >>> Flintstones=wilma:bam-bam:fred >>> Rubbles=barney Using the syntax $() for both functions renders also the order above unusable (here FSTONES will get reset by assemble_fam2 then). Like $() will revert an unrelated variable to a former state. There also seems to be difference between using run_aliases or issuing both commands by hand. Using `` for both functions looks like being safe though and covers all cases. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
Hi, > Am 28.02.2017 um 11:00 schrieb Andreas Schwab : > > On Feb 28 2017, Geoff Hull wrote: > >> If I "source" the attached file (i.e. ". test_aliases") in a bash session, >> then run the following: >> >> assemble_fam1 >> assemble_fam2 >> say_families >> >> I see the following output: >> >> Flintstones=wilma:bam-bam:fred >> Rubbles=barney In which version of Bash are you observing this? For me it's working using this order, but when I swap assemble_fam1 and assemble_fam2 I observe a strange behavior, that RUBBLES gets reset and I get your output: $ assemble_fam1 $ assemble_fam2 $ say_families Flintstones=wilma:bam-bam:fred Rubbles=betty:pebbles:barney $ reset_vars $ assemble_fam2 $ say_families Flintstones= Rubbles=betty:pebbles:barney $ assemble_fam1 $ say_families Flintstones=wilma:bam-bam:fred Rubbles=barney This I have in 4.2 and 4.4. $ reset_vars + reset_vars + unset FSTONES RUBBLES $ assemble_fam2 + barney ++ echo barney + RUBBLES=barney $ say_families + RUBBLES=betty:pebbles:barney + say_families + echo Flintstones= Flintstones= + echo Rubbles=betty:pebbles:barney Rubbles=betty:pebbles:barney $ assemble_fam1 + fred ++ echo fred + FSTONES=fred + FSTONES=wilma:bam-bam:fred $ say_families + say_families + echo Flintstones=wilma:bam-bam:fred Flintstones=wilma:bam-bam:fred + echo Rubbles=barney Rubbles=barney > It seems like the shell is eating an extra newline. Try typing an empty > line after assemble_fam2: The extra newline doesn't help for the observation above. While defining assemble_famX in one line for both does as mentioned by Geoff. -- Reuti signature.asc Description: Message signed with OpenPGP using GPGMail
Re: "Variation" in Command Substitution Behaviour
On Feb 28 2017, Geoff Hull wrote: > If I "source" the attached file (i.e. ". test_aliases") in a bash session, > then run the following: > > assemble_fam1 > assemble_fam2 > say_families > > I see the following output: > > Flintstones=wilma:bam-bam:fred > Rubbles=barney It seems like the shell is eating an extra newline. Try typing an empty line after assemble_fam2: $ set -x $ assemble_fam1 + fred ++ echo fred + FSTONES=fred + FSTONES=wilma:bam-bam:fred $ assemble_fam2 + barney ++ echo barney + RUBBLES=barney $ + RUBBLES=betty:pebbles:barney $ say_families + say_families + echo Flintstones=wilma:bam-bam:fred Flintstones=wilma:bam-bam:fred + echo Rubbles=betty:pebbles:barney Rubbles=betty:pebbles:barney 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."
