> unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
> unicorn:~$ njobs walsh
> unicorn:~$ echo "$walsh"
> 3
>
> Now you just need to add sanity-checking on the argument of njobs, to
> avoid whatever code injection the malicious caller wants to perform.
I can't fathom the switch to eval there. Why not printf -v "$1" %s "$_n", for
example? It even rejects invalid identifiers.
--
Kerin Millar
On Tue, 29 Jun 2021 17:02:16 -0400
Greg Wooledge wrote:
> On Tue, Jun 29, 2021 at 09:47:30PM +0100, Kerin Millar wrote:
> > On Tue, 29 Jun 2021 16:35:28 -0400
> > Greg Wooledge wrote:
> >
> > > unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$
n that intrinsically performs
variable assignment, only to redundantly assign the result of the expansion to
the same variable once again. In a roundabout fashion, it ends up proving
Greg's point. I'd suggest temporarily disavowing yourself of the
${parameter:=word} form, for the time being.
--
Kerin Millar
x1 -c" and also taking a look at
https://mywiki.wooledge.org/BashFAQ/052.
--
Kerin Millar
t
you were trying to make.
#!/bin/bash
shopt -s expand_aliases
alias done=""
f() {
for var; do
:
done
}
Running this script results in the following error.
line 8: syntax error near unexpected token `}'
line 8: `}'
Not defining the alias does, indeed, allow for the revised script to execute
successfully.
--
Kerin Millar
bash happens to tolerate the
use of a circumflex, in which case it should behave in the exact same way. Are
you able to show a concrete example of one behaving differently from the other?
--
Kerin Millar
On Fri, 20 Aug 2021 23:33:38 +
hancooper wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, August 20, 2021 8:00 PM, Kerin Millar wrote:
>
> > On Fri, 20 Aug 2021 19:28:25 +
> > hancooper via Bug reports for the GNU Bourne Again SHell bug-bash@gnu.org
>
et it
wrong, yet EPOCHSECONDS is permitted to get it right. The discrepancy certainly
came as a surprise to me.
$ TZ=UTC faketime '1970-01-01' bash -c 'declare -p EPOCHSECONDS'
declare -- EPOCHSECONDS="0"
$ TZ=UTC faketime '1969-12-31' bash -c 'declare -p EPOCHSECONDS'
declare -- EPOCHSECONDS="-86400"
--
Kerin Millar
((i++)); echo $?
> 1
This makes use of a post-increment operator. The evaluated number is 0.
>
> i is always set to 0, the result is always non-zero, but the return code
> differs.
This is to be expected. It works the same way as in other languages, such as C.
You should use the operator that reflects your intent.
--
Kerin Millar
the arithmetical context. See
https://mywiki.wooledge.org/BashProgramming/05#Arithmetic_Expansion for some
other examples. As things stand, your only option is to validate or sanitise
abitrarily specified array indices before proceeding to use them in such a
context.
--
Kerin Millar
rability on the part of bash, much less a zero-day.
--
Kerin Millar
hat
it is beyond the purview of the shell.
[1]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
--
Kerin Millar
27;--', @args); # better
Granted, one would normally use the native unlink function but that's besides
the point.
--
Kerin Millar
(Copying the list back in ...)
On Fri, 19 Nov 2021 17:37:54 +0100
Andreas Kusalananda Kähäri wrote:
> On Fri, Nov 19, 2021 at 03:56:21PM +0000, Kerin Millar wrote:
> > On Fri, 19 Nov 2021 10:05:39 -0500
> > Marshall Whittaker wrote:
> >
> > > Fair. I'm not
On Fri, 19 Nov 2021 13:40:16 -0600
Eric Blake wrote:
> On Fri, Nov 19, 2021 at 03:56:21PM +0000, Kerin Millar wrote:
> > On Fri, 19 Nov 2021 10:05:39 -0500
> > Marshall Whittaker wrote:
> >
> > > Fair. I'm not saying anyone has to change it, but I will call
ts. Incidentally, by default, the sshd_config(5) shipped by
macOS defines "AcceptEnv LANG LC_*", meaning that it honours all of the
environment variables pertaining to the locale, as conveyed by the ssh(1)
client.
--
Kerin Millar
d to terminals (as determined by isatty(3)), or one
started with the -i option."
I think that the addition of this word might increase the probability of the
sentence being (correctly) interpreted in the fashion of "an interactive shell
is either one that fulfils ( criteria A ) or ( criteria B )", keeping in mind
that the -i option always renders bash interactive.
--
Kerin Millar
command substitution causes a subshell to be created. The
command, exit 1, is not run by the shell that the kernel loaded to interpret
your script.
--
Kerin Millar
s, such as https://github.com/scop/bash-completion. As such, you will
need to discern the offending script so as to establish its provenance.
--
Kerin Millar
t up to be multilib-capable. Still, all
of this is outside of the purview of the shell. What bash is doing in response
to the failed syscall is to report the exact error that it raised. It doesn't
seem reasonable to expect for it to do anything else.
--
Kerin Millar
. heredoc.sh
> bash: warning: here-document at line 2 delimited by end-of-file (wanted
> `SCRIPT')
> sed: file - line 3: unknown command: `S'
>
>
> $ . heredoc-ok.sh
> #!/bin/bash
> sed -f - heredoc-ok.sh <<-SCRIPT
> ␣␣s/else/else/
> ⭲ s/else/else/
> ⭲ SCRIPT
>
>
> Fix:
>
> I think it'd be convenient if Heredoc supports indentation with spaces at the
> delimiter line, too.
One issue with this proposal is that it would violate the rules of the Shell
Command Language, per
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04.
--
Kerin Millar
ing
Taking Perl as a counter-example, there is no problem issuing the equivalent
setlocale call.
$ perl -MPOSIX=locale_h -E 'if (setlocale(LC_ALL, "en_US.ISO-8859-1")) { say
"Successfully changed LC_ALL to ", setlocale(LC_ALL) }'
Successfully changed LC_ALL to en_US.ISO-8859-1
Is there a particular reason that bash appears to reject the attempt to assign
"en_US.ISO-8859-1" to LC_CTYPE?
--
Kerin Millar
exit
1
fi
Alternatively, if it is considered necessary to issue ls from within the
function:
copy_files() {
cp /new/file1 /production/path/ &&
cp /new/file2 /production/path/ &&
important-job /production/path/file1 /production/path/file2 || return
ls -l /production/path | mail -s "all-good" not...@company.com
true
}
Ultimately, which approach is easier to reason with? Consider it as an open
question.
--
Kerin Millar
tes and no
> value.
>
> It may be nice to also add a "force" option for `unset' that makes it
> actually unset the variable if it is `local'. Since this could be
> useful in some cases and it won't be possible after the behaviour is
> changed.
>
--
Kerin Millar
Hi Martin,
On Sat, 30 Jul 2022 11:47:01 +1000
Martin D Kealey wrote:
> On Fri, 29 Jul 2022 at 18:51, Kerin Millar wrote:
>
> > 5.0 added a localvar_unset option that impedes the behaviour of 'popping'
> > from the outermost scope.
I would have preferred for the
rsive parser.
To put it in perspective, it transpired that only one ebuild (package) in its
20620-strong repo was affected and that none of the portions of portage that
are written in bash were affected (until now). My concern is that these
ostensible concessions to backward-compatibility will end up causing more
problems than will be solved.
--
Kerin Millar
On Mon, 29 Aug 2022 09:53:39 -0400
Chet Ramey wrote:
> On 8/26/22 9:29 PM, Kerin Millar wrote:
> > Hi Chet,
> >
> > On Fri, 26 Aug 2022 14:28:00 -0400
> > Chet Ramey wrote:
> >
> >> 1. Changes to Bash
> >>
> >> a. Added
On Wed, 31 Aug 2022 10:55:58 -0400
Chet Ramey wrote:
> On 8/29/22 12:28 PM, Kerin Millar wrote:
>
> >>> For extglob to be arbitrarily enabled in either context is unexpected
> >>> (and undesirable).
> >>
> >> The conditional command behavior is c
e affected, as is demonstrated by the
attached script. See, also, the original bug report at
https://bugs.gentoo.org/873931.
--
Kerin Millar
gentoo-bug-873931-reproducer-r1.bash
Description: Binary data
On Thu, 6 Oct 2022 15:49:26 -0400
Chet Ramey wrote:
> On 10/2/22 4:51 AM, Kerin Millar wrote:
>
> > $ declare -p BASH_VERSION
> > declare -- BASH_VERSION="5.2.0(1)-release"
> > $ BASH_COMPAT=50; shopt extglob; : $(: $(: $(:))); shopt extglob
> > ex
x27;"' line EOF '' | bash
bash: line 5: warning: here-document at line 2 delimited by end-of-file (wanted
`EOF
')
line
EOF
$
For comparative purposes, I tried dash-0.5.11.5, ksh-2020 and busybox-1.34.1
(ash), all of which appear to get it right.
$ printf '%s\n' 'cat <<"EOF' '"' line EOF '' | dash
line
$
$ printf '%s\n' 'cat <<"EOF' '"' line EOF '' | ksh
line
$
$ printf '%s\n' 'cat <<"EOF' '"' line EOF '' | busybox sh
line
$
--
Kerin Millar
tle
> tporecommend it) then this would be something that would have to
> be copied. Doing so is pointless however, no real scripts, as
> distinct from test cases, are going to be using a here doc
> delim with embedded newlines, so this would be a case to do better.
Indeed. Thanks for the clarification.
--
Kerin Millar
quot; in
the near future?
--
Kerin Millar
t; backslash is no longer possible when using BASH_COMPAT=4.2.
>
> On 9 Feb 2023 at 15:57Z Chet Ramey wrote:
> > shopt -u patsub_replacement
>
> Surely that should be automatic with compat51 and earlier, since it's a
> breaking change to previous behaviour?
Somewhat related is https://bugs.gentoo.org/881383.
--
Kerin Millar
rt any critical fixes between upstream
releases.
> So if I make "Bash6" as a fork of Bash 5.1, with the following guarantees,
> would anyone be interested in adopting it?
>
It seems like a lot to take on but count me in as being interested.
--
Kerin Millar
of being a potential alternative to the
invocation of stty(1) with the "size" operand (an operand which will eventually
be standard, but isn't yet).
--
Kerin Millar
On Tue, 21 Feb 2023 15:44:34 -0500
Chet Ramey wrote:
> On 2/21/23 4:18 AM, Kerin Millar wrote:
> > I am writing to report that the documented behaviour of the checkwinsize
> > shopt can be impeded by the use of the subshell.
>
> It hasn't worked that way since at l
le without quotes, the same illogical.
>
> I am curious if I am the first guy encounter such a situation.
Well observed. I can confirm this strange behaviour. I just want to add that
5.1.16 behaves sensibly, with [[ ]] always raising an error in an interactive
shell.
--
Kerin Millar
On Thu, 23 Feb 2023 11:07:52 +0100
alex xmb ratchev wrote:
> i [[ daily , never had such..
This observation isn't helpful unless you account for which version of bash you
are using. In any case, the report is accurate and it describes a post-5.1
regression.
--
Kerin Millar
2-98.html
Though I was aware of these behaviours, I do find the POSIX wording to be
unclear as concerns the observations made by the second link, to say the least.
I would add that it is possible to have it both ways, so to speak, though the
means of going about it are no less confusing than the topic at large.
$ IFS=,
$ str="a,b"
$ arr=($str""); declare -p arr
declare -a arr=([0]="a" [1]="b")
$ str="a,b,"
$ arr=($str""); declare -p arr # duly coercing an empty field that some may
expect or wish for
declare -a arr=([0]="a" [1]="b" [2]="")
--
Kerin Millar
issuing a formal request for clarification. Clearly, there
exists a prevailing consenus across implementations (bash included). For the
matter not to be broached by the specification - at least, not by my reading -
seems irregular.
--
Kerin Millar
rect. If IFS=",", then a read -r statement must assign the
No it isn't.
> first value to the single variable, and disregard the rest.
No it musn't. Read
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html and pay
particular attention to the definition of what must happen where there are
fewer vars (names) than fields encountered.
--
Kerin Millar
t bash affords one the luxury of using read -a before
proceeding to check the size of the resulting array.
--
Kerin Millar
7;; echo $?
bash: -c: line 1: syntax error near `;'
bash: -c: line 1: `[[ ]]; echo fin'
2
The development branch behaves as 5.1 does. Being uncertain as to whether this
is a result of the issue having been identified prior, I determined that it was
worth reporting.
--
Kerin Millar
On Fri, 16 Jun 2023 14:25:54 -0400
Chet Ramey wrote:
> On 6/15/23 8:57 PM, Kerin Millar wrote:
> > As below.
> >
> > $ bash -c 'declare -p BASH_VERSION'
> > declare -- BASH_VERSION="5.2.15(1)-release"
> > $ bash -c '[[ ]]; echo fin&#
nted to be evaluated
in the original shell
4) an alias is thus declared in the original shell
As Lawrence advised in a different thread, such questions would be more
appropriately posed at the help-bash list.
--
Kerin Millar
On Wed, 21 Jun 2023 14:11:28 +0530
LitHack wrote:
> But why this not worked in zsh.
I don't use zsh. A fairly plausible explanation would be that its alias builtin
ignores the request to declare an alias, if issued in a subshell.
--
Kerin Millar
On Wed, 21 Jun 2023 09:01:20 -0400
Greg Wooledge wrote:
> On Wed, Jun 21, 2023 at 09:54:30AM +0100, Kerin Millar wrote:
> > On Wed, 21 Jun 2023 14:11:28 +0530
> > LitHack wrote:
> >
> > > But why this not worked in zsh.
> >
> > I don't use zsh. A
()"'; echo $?
BASH_ARG
0
$ bash -c 'f() { shift; printf %s\\n "${1%%=*}"; }; eval "f -a BASH_ARGC=()"';
echo $?
bash: eval: line 1: syntax error near unexpected token `('
bash: eval: line 1: `f -a BASH_ARGC=()'
2
$ bash -c 'f() { shift; printf %s\\n "${1%%=*}"; }; eval "f -a BASH_ARG=()"';
echo $?
bash: eval: line 1: syntax error near unexpected token `('
bash: eval: line 1: `f -a BASH_ARG=()'
2
--
Kerin Millar
you're using 5.2, which improves the quoting strategy for
declare/typeset. Unfortunately, it's not something that I can rely upon in
production (not least, because I can't yet assume that everyone is using bash
>=5.2).
--
Kerin Millar
On Mon, 26 Jun 2023 11:51:58 +0200
alex xmb ratchev wrote:
> On Mon, Jun 26, 2023, 11:33 Kerin Millar wrote:
>
> > On Mon, 26 Jun 2023 17:09:47 +1000
> > Martin D Kealey wrote:
> >
> > > Hi Eli
> > >
> > > How about using the shell it
hink, by the way.
--
Kerin Millar
On Mon, 26 Jun 2023 12:03:47 +0200
alex xmb ratchev wrote:
> On Mon, Jun 26, 2023, 12:01 Kerin Millar wrote:
>
> > On Mon, 26 Jun 2023 11:51:58 +0200
> > alex xmb ratchev wrote:
> >
> > > On Mon, Jun 26, 2023, 11:33 Kerin Millar wrote:
> > >
On Tue, 27 Jun 2023 02:23:23 +0700
Robert Elz wrote:
> Date:Mon, 26 Jun 2023 10:32:19 +0100
> From: Kerin Millar
> Message-ID: <20230626103219.0f74c089c616248cee6ab...@plushkava.net>
>
>
> | Further, declare is granted special treatment
=$'\nNONEXISTENT=' ./declare-P | grep ^NONEXISTENT
NONEXISTENT
All of this lends further credence to Eli's post. Parsing declare -F is a minor
nuisance, whereas parsing declare -p is broken by design. While the format of
declare -p improved for 5.2, there is no guarantee of forward-compatibility.
--
Kerin Millar
On Tue, 27 Jun 2023 21:52:53 +0200
of1 wrote:
> On 27/06/2023 21:05, Kerin Millar wrote:
> > It doesn't work at all for >=5.2. The reason for this is interesting and I
> > may make a separate post about it.
> >
> > Prior to 5.2, it can easily be tric
On Wed, 28 Jun 2023 12:42:16 +0200
Fabien Orjollet wrote:
> On 28/06/2023 00:40, Kerin Millar wrote:
> > On Tue, 27 Jun 2023 21:52:53 +0200
> > of1 wrote:
> >
> >> On 27/06/2023 21:05, Kerin Millar wrote:
> >>> It doesn't work at all for >=5.
ash: line 1: BASHOPTS: readonly variable
However:
$ bash -c 'declare BASHOPTS=1; echo FIN'
bash: line 1: BASHOPTS: readonly variable
FIN
This seems rather inconsistent. Also, it is confusing for bash to quit without
indicating why it did so.
--
Kerin Millar
On Thu, 29 Jun 2023 08:51:58 -0400
Chet Ramey wrote:
> On 6/28/23 1:14 PM, Kerin Millar wrote:
> > This report is based on an observation made within the depths of this
> > thread: https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00094.html.
> >
> > Attemptin
On Thu, 29 Jun 2023 11:55:12 +0200
Sebastian Luhnburg wrote:
> #!/usr/bin/env bash
>
> initial_password="\$abc&xyz"
> echo "initial password: " $initial_password
> printf -v password '%q' $initial_password
> echo "initial password with escaped characters: " $password
> bash << EOF
> echo "passwo
> noassign variables should change $?.
That seems reasonable to me. It would also make it less likely that the
evaluation of the prior output of declare -p - be in whole or in part - affects
the value of $?, which seems like a win.
--
Kerin Millar
possible to match any name. To be clear, I am not as concerned with the matter
as I was at the time that the bug was initially filed but would still welcome
any potential improvement, if it is at all feasible.
--
Kerin Millar
On Sat, 01 Jul 2023 00:19:41 +0700
Robert Elz wrote:
> Date:Thu, 29 Jun 2023 23:05:38 +0100
> From: Kerin Millar
> Message-ID: <20230629230538.cbef14a75694143ccf034...@plushkava.net>
>
> | The thing is that portage also has a legitimate stak
On Sat, 01 Jul 2023 02:25:33 +0700
Robert Elz wrote:
> Date:Fri, 30 Jun 2023 18:35:34 +0100
> From: Kerin Millar
> Message-ID: <20230630183534.85da7986a24855126bfea...@plushkava.net>
>
> | This can be trivially foiled.
>
> You mean
me ago.
>
> If POSIX mandates that '--' not be taken as the end of options, then the
> safe thing would be to simply not have echo take any options. Obviously,
> that would break backwards compatibility, so you'd want this to be optional
> behavior that the shell programmer can enable if desired.
echo() { local IFS=' '; printf '%s\n' "$*"; }
--
Kerin Millar
with three arguments. The first of
these arguments is -e, which is treated as an option.
--
Kerin Millar
#x27;t
actually prove that an array variable is set, even with 5.1.
$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.1.16(1)-release
$ declare -A map; [[ -v 'map[@]' ]]; echo $?
1
Frankly, the only interface that I would trust for this is declare -p, which is
a wasteful one; there is no way to instruct the declare builtin to refrain from
writing out the elements of an array.
--
Kerin Millar
test will be true in the case that assoc has been
defined as a variable that is not an array.
$ unset -v assoc; assoc=; (( ${#assoc[@]} > 0 )); echo $?
0
--
Kerin Millar
On Tue, 29 Aug 2023 11:34:21 -0400
Chet Ramey wrote:
> On 8/29/23 11:30 AM, Kerin Millar wrote:
> > Hi,
> >
> > On Tue, 29 Aug 2023 16:32:36 +0200
> > Christian Schneider wrote:
> >
> >> Hi all,
> >>
> >> not sure if this intended o
On Tue, 29 Aug 2023 11:44:13 -0400
Chet Ramey wrote:
> On 8/29/23 11:38 AM, Kerin Millar wrote:
> > On Tue, 29 Aug 2023 11:24:43 -0400
> > Chet Ramey wrote:
> >
> >> If you want to check whether an array variable is set, you can check
> >> whether it has
resented link to the manual with *6.7 Arrays*
> there is no explanation for *declare -p *:(
It's a builtin command, so it's listed within the SHELL BUILTIN COMMANDS
section. Also, you may use the help builtin to display some (less detailed)
documentation.
$ help declare | grep -- -p
-pdisplay the attributes and value of each NAME
--
Kerin Millar
t;append me")
bash: declare: RESULT: not found
Note that the second declare command correctly raises an error because RESULT
is not visible in its scope. Used judiciously, local can help to avoid the
writing of needless bugs.
--
Kerin Millar
o
be a keyword there, even though it is. In any case, here is a temporary
workaround for this regression.
$ declare -- BASH_VERSION="5.2.15(1)-release"
$ var2=$(:; time { echo foo; echo bar; })
real0m0.000s
user0m0.000s
sys 0m0.000s
--
Kerin Millar
r BASH arrays
> To: Kerin Millar
>
>
> Thanks for the detailed explanations of *declare *.
>
> As to the idea behind of my request:
> 1) I need local variable RESULT as empty string (not array)
> 2) this RESULT should collect symbols taken from other strings using
>
se DOLPAREN:
> + case DOLBRACE:
> return 1;
>default:
Would you mind supplying a diff for 5.2.15? For that version, I get:
./parse.y: In function ‘time_command_acceptable’:
./parse.y:3139:14: error: ‘DOLBRACE’ undeclared (first use in this function);
did you mean ‘Q_DOLBRACE’
--
Kerin Millar
On Fri, 1 Sep 2023 10:29:29 -0400
Chet Ramey wrote:
> On 9/1/23 10:27 AM, Kerin Millar wrote:
>
> > Would you mind supplying a diff for 5.2.15? For that version, I get:
> >
> > ./parse.y: In function ‘time_command_acceptable’:
> > ./parse.y:3139:14: error: ‘DOLB
s to be given a pipeline.
--
Kerin Millar
to
say that nobody uses it (nor should anybody wish to upon realising how it
works).
--
Kerin Millar
On Tue, 5 Sep 2023 16:04:50 +0200
alex xmb ratchev wrote:
> On Mon, Sep 4, 2023, 15:19 Kerin Millar wrote:
>
> > On Mon, 4 Sep 2023 14:46:08 +0200
> > Léa Gris wrote:
> >
> > > Le 04/09/2023 à 14:18, Dan Jacobson écrivait :
> > > > Shouldn'
uot;$(printf 'abcdef0123456789/%.0s' {0..20})"
> > $ mkdir -p /tmp/$long_name
> > $ cd /tmp/$long_name
> > $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
> >
>
> foo=$' .. '
> not
> foo=' .. '
$'' quoting is not required for that particular definition of PS1.
--
Kerin Millar
The issue has not yet been addressed by any available 5.2 patchlevel. Should
you wish to patch 5.2 yourself - as I did - apply the above-mentioned change
while ignoring the addition of "case DOLBRACE:".
--
Kerin Millar
On Thu, 7 Sep 2023 17:33:45 +0200
alex xmb ratchev wrote:
> On Thu, Sep 7, 2023, 16:51 Kerin Millar wrote:
>
> > On Thu, 7 Sep 2023 15:53:03 +0200
> > alex xmb ratchev wrote:
> >
> > > On Thu, Sep 7, 2023, 15:46 Gioele Barabucci wrote:
> > >
> &g
255
This is the appropriate outcome. It would be undesirable for "ff" to be treated
as a variable name identifier there.
In your case, the error is that the letters "r", "e" and "s" have ordinal
values that are too high to be valid for base 10, but they could have been
valid for a higher base.
$ echo $(( 29#res1 ))
671090
--
Kerin Millar
On Mon, 18 Sep 2023 04:56:18 +0200
alex xmb ratchev wrote:
> On Mon, Sep 18, 2023, 04:03 Kerin Millar wrote:
>
> > Hi Victor,
> >
> > On Sun, 17 Sep 2023, at 8:59 PM, Victor Pasko wrote:
> > > Hi,
> > >
> > > Could you please take a look at
1]. Why?
[1] ((, for, array subscripts, string-slicing parameter expansions etc
--
Kerin Millar
On Tue, 19 Sep 2023 20:00:13 +0700
Robert Elz wrote:
> Date:Tue, 19 Sep 2023 09:52:21 +0100
> From: "Kerin Millar"
> Message-ID: <4c2e3d39-0392-41ae-b73c-3e17296a9...@app.fastmail.com>
>
> | On Tue, 19 Sep 2023, at 8:40 AM, Victor
On Wed, 20 Sep 2023 01:41:30 +0700
Robert Elz wrote:
> Date:Tue, 19 Sep 2023 18:09:13 +0100
> From: Kerin Millar
> Message-ID: <20230919180913.bd90c16b908ab7966888f...@plushkava.net>
>
> | > | On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko
On Tue, 19 Sep 2023 21:29:32 +0200
alex xmb ratchev wrote:
> On Tue, Sep 19, 2023, 21:14 Kerin Millar wrote:
>
> > On Wed, 20 Sep 2023 01:41:30 +0700
> > Robert Elz wrote:
> >
> > > Date:Tue, 19 Sep 2023 18:09:13 +0100
> > > From:
e able to consider res1 and res2
>
>
> optional as in make default values in if empty ?
No. Victor wants for, say, "10#res1" to consider res1 as an identifier, instead
of a number. I can't know how it could be stated any more clearly.
--
Kerin Millar
or decorating native error messages is dubious. There is only so much
that can be said without making too many assumptions about the underlying
platform or, worse, implementing dodgy heuristics. Although, there is a
heuristic that tries to determine whether ENOENT was caused by a script
containing a shebang specifying an invalid interpreter, which does not help in
this case.
--
Kerin Millar
fulfils the requirements laid
out by 2.8.1 Consequences of Shell Errors for both interactive and
non-interactive instances.
$ exec dash
$ exit foo
dash: 1: exit: Illegal number: foo
$ echo $?
2
$ printf %s\\n 'exit foo' 'echo done' | dash
dash: 1: exit: Illegal number: foo
$ echo $?
2
--
Kerin Millar
pirit of section 2.8.1 and that it is neither
helpful nor useful. Instead, I think that it should continue to print the
diagnostic message and set $? to 2, but not exit the interactive instance.
--
Kerin Millar
On Mon, 9 Oct 2023 14:56:24 -0400
Chet Ramey wrote:
> On 10/9/23 1:57 AM, Kerin Millar wrote:
>
> > Just to add that, while POSIX does not specify the behaviour of the exit
> > builtin where its operand "is not an unsigned decimal integer or is greater
> >
n interactive subshell; if the parameters get exported to there,
> then "CLONE ALL THE THINGS" behavior just keeps propagating through the
> scripts. Hilarity ensues.)
>
>
> === Reproduction
Bash employs dynamic scoping and the behaviour of unset can be confusing in
some cases (with local variables in particular). However, given the code that
you presented, I am unable to reproduce the claimed behaviour in any of 5.1.16,
5.2.15 and the devel branch. In the absence of a minimal reproducible example,
it is difficult to comment. Incidentally, echo is not ideal as a tool for
determining the state of a given variable. Consider "declare -p INSIDE OUTSIDE"
instead.
--
Kerin Millar
..|
0030 e2 80 8b e2 80 8b 0a |...|
0037
Bash prints these non-printing characters within the diagnostic message exactly
as they are, making the fact harder to diagnose. Nevertheless, it is quite
correct in pointing out that it is a bad substitution.
--
Kerin Millar
you a long sequence of
> > ASCII characters.
> >
>
> But ASCII_SET is not unset so -word must not be used
It behaves precisely as the manual states. The parameter, ASCII_SET, is neither
unset nor null (empty). Therefore, the value of the parameter is substituted,
rather than the given word of "10:1".
--
Kerin Millar
On Fri, 27 Oct 2023 19:28:15 +0700
Victor Pasko wrote:
> See my comments below inline
>
> On Fri, Oct 27, 2023 at 2:50 AM Kerin Millar wrote:
>
> > On Fri, 27 Oct 2023 02:00:01 +0700
> > Victor Pasko wrote:
> >
> > > -- Forwarded message ---
On Fri, 27 Oct 2023 15:34:16 +0100
Kerin Millar wrote:
> Keep in mind that the Shell Command Language specification requires that
> "Default Value" parameter expansion be implemented in the way that it is, and
> that there are countless scripts that depend on the statu
sh: 'a >> 4: syntax error: operand expected (error token is "'a >> 4")
You are in an arithmetic context there, and must abide by its rules of syntax
(which are mostly those of ANSI C, not the printf utility). Obtain the integer
value first.
$ char=a; printf -v ord %d "'${char}"; echo $(( ord >> 4 ))
6
--
Kerin Millar
On Tue, 5 Dec 2023 23:46:51 +
Ole Tange via Bug reports for the GNU Bourne Again SHell
wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> uname output: Linux aspire 5.15.0-88-generic #9
1 - 100 of 152 matches
Mail list logo
