On Sun, 19 May 2024, at 5:08 PM, alex xmb sw ratchev wrote:
> On Sat, May 18, 2024, 04:54 Zachary Santer wrote:
>
>> Was «difference between read -u fd and read <&"$fd"» on help-b...@gnu.org
>>
>> On Thu, May 16, 2024 at 12:51 AM Kerin Millar wrote:
On Sat, 18 May 2024, at 3:53 AM, Zachary Santer wrote:
> Was «difference between read -u fd and read <&"$fd"» on help-b...@gnu.org
>
> On Thu, May 16, 2024 at 12:51 AM Kerin Millar wrote:
>>
>> On Thu, 16 May 2024, at 3:25 AM, Peng Yu wrote:
>> >
c:
> stdin: read: Input/output error". Or we can ctrl C.
> Version 5.2
Though already asked, what were you intending for it to do?
--
Kerin Millar
On Wed, 8 May 2024, at 7:07 PM, Dale R. Worley wrote:
> "Kerin Millar" writes:
>> On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote:
>>> anonymous writes:
>>>> [...]
>
>> It's likely that your reply will never be seen by the anonymous
>
On Tue, 7 May 2024, at 7:14 PM, Chet Ramey wrote:
> On 5/7/24 1:42 PM, Kerin Millar wrote:
>> On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
>>> On 5/5/24 3:39 PM, Kerin Millar wrote:
>>>
>>>> Such is the extent to which I concur that I find even
On Tue, 7 May 2024, at 3:27 PM, Chet Ramey wrote:
> On 5/5/24 3:39 PM, Kerin Millar wrote:
>
>> Such is the extent to which I concur that I find even -l to be irritating.
>
> The option character isn't important. Is it useful to have an additional
If it were of no importance
On Tue, 7 May 2024, at 5:24 AM, Phi Debian wrote:
> On Mon, May 6, 2024 at 7:51 PM Kerin Millar wrote:
>>
>>
>> I'll put it in a little more detail, though no less plainly. I find the
>> terminology of "libraries" and "modules" to be spe
rd,
> the expansion of the first parameter is joined with the begin‐
> ning part of the original word, and the expansion of the last
> parameter is joined with the last part of the original word.
> When there are no positional parameters, "$@" and $@ expand to
> nothing (i.e., they are removed).
>
> Dale
It's likely that your reply will never be seen by the anonymous Savannah issue
filer.
--
Kerin Millar
e addressed by a marginally more flexible source
builtin. Indeed, it is unclear that they can be - or ever will be - addressed.
Presently, bash is what it is: a messy, slow, useful implementation of the
Shell Command Language with an increasing number of accoutrements, some of
which are fine and others of which are less so (and virtually impossible to get
rid of). As curmudgeonly as it may be to gripe over variable and option names,
this is why the import of library, as a word, does not rest at all well in
these quarters. That aside, I do not find the premise of the patch series to be
a convincing one but would have little else to say about its prospective
inclusion, provided that the behaviour of the posix mode were to be left
unchanged in all respects.
--
Kerin Millar
about the
> files being sourced, when in fact there is nothing special about
> them at all -- they can still run arbitrary code, modify the global
> namespace, etc. etc. etc. etc.
Such is the extent to which I concur that I find even -l to be irritating.
--
Kerin Millar
On Sat, 27 Apr 2024 23:56:28 +0200
Andreas Schwab wrote:
> On Apr 27 2024, Kerin Millar wrote:
>
> > In the course of trying this in bash-5.3-alpha, I noticed something else.
> > If ':?aa' is not the only entry in the current working directory, readline
> > behaves
ly entry in the current working directory, readline behaves
as if : is an ambiguous completion. That is:
# mkdir ':?aa'
# touch 'something-else'
# rmdir :
... produces nothing until pressing the tab key a second time, after which both
entries are listed while the content of readline's input buffer remains
unchanged.
--
Kerin Millar
On Sat, 27 Apr 2024 14:09:29 +0200
Andreas Schwab wrote:
> On Apr 27 2024, Kerin Millar wrote:
>
> > At some point after upgrading to bash-5.3-alpha, the following message
> > appeared in my kernel ring buffer.
> >
> > [700406.870502] bash[3089019]: memfd_cr
uncertain as to what bash was being tasked with at the time
that it was logged. The inference of the message seems clear, however. The
presently running kernel is 6.6.28.
--
Kerin Millar
ERSION="5.1.16(1)-release"
declare -- var1="foo
bar"
bar"are -- var2="foo
In my opinion, that demonstrates that the new approach is obviously superior.
That is, the output of 5.2 there is vastly more legible to me; to make sense of
the output of 5.1, I might have to rely on a utility such as od or hexdump. Put
another way, this style of quoting is tremendously helpful for conveying
strings that do not exclusively consist of graphemes.
Anyway, it look as though the xtrace mode has been similar adjusted.
--
Kerin Millar
On Mon, 22 Apr 2024, at 8:56 AM, Oğuz wrote:
> On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote:
>> I cannot find anything in the manual that concretely explains why bash
>> behaves as it does in this instance.
>
> Me neither, but the current behavior is useful. Take `whi
On Mon, 22 Apr 2024, at 7:44 AM, Kerin Millar wrote:
> On Mon, 22 Apr 2024, at 7:13 AM, felix wrote:
>> Hi,
>>
>> Comming on this very old thread:
>>
>> On Wed, 4 Dec 2013 14:40:11 -0500, Greg Wooledge wrote:
>>>
>>> The most obvious differen
foreground pipeline"
> by "command" under "?" paragraph.
It's worth reading the section of the manual that concerns "Pipelines". Not
least, to concretely understand what they are in grammatical terms, but also to
understand that the exit status of a pipeline is "the exit status of the last
command, unless the pipefail option is enabled". That is, the last command that
constitutes the pipeline; there need not be more than one.
--
Kerin Millar
On Thu, 11 Apr 2024, at 4:57 PM, Oğuz wrote:
> On Thursday, April 11, 2024, Kerin Millar wrote:
> Notwithstanding, I tried declaring the same function in an interactive
> instance of dash and found that the alias within the command
> substitution does end up being expanded, which
alias echo='echo PREFIX'
$ foo() { output="$(echo "hello world")"; printf '%s\n' "$output"; }
$ unalias echo
$ echo ok
ok
$ foo
PREFIX hello world
The behaviour of dash seems more logical to me, though I am uncertain as to
which shell is in the right.
--
Kerin Millar
ally specifies the following form:
- for name sequential_sep do_group
Note that "linebreak" implies either a "newline_list" or nothing at all. With
that in mind, here are some examples.
for var do :; done
for var in 1; do :; done
for var in; do :; done
for var; do :; done
--
Kerin Millar
On Tue, 9 Apr 2024 10:42:58 +1200
Martin D Kealey wrote:
> On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
>
> > the method by which vim amends files is similar to that of sed -i.
> >
>
> I was about to write "nonsense, vim **never** does that for me", but
in this thread spoke of it. It isn't a panacea
because a sufficiently large compound command can cause bash to run out of
stack space. In that case, all one can do is to break the script down further
into additional, smaller, functions.
--
Kerin Millar
On Mon, 08 Apr 2024 00:23:38 +0300
ad...@osrc.rip wrote:
> On 2024-04-07 16:49, Kerin Millar wrote:
> > On Sun, 7 Apr 2024, at 5:17 AM, ad...@osrc.rip wrote:
> >> Hello everyone!
> >>
> >> I've attached a minimal script which shows the issue, an
e potentially adverse consequences of
performing an in-place edit is to to refrain entirely from performing in-place
edits.
--
Kerin Millar
such, your example could be amended as:
while read -r -u3 var; do ... processing commands ...; done 3< <(... generating
commands ...)
In the event that the processing commands are known not to attempt to read from
STDIN, that may be further reduced to:
while read -r var; do ... processing commands ...; done < <(... generating
commands ...)
--
Kerin Millar
sn't have such an option.
It has such an option in the case that SYSLOG_HISTORY and SYSLOG_SHOPT are
defined.
--
Kerin Millar
unset -v 'job_by[$pid]'
}
worker() {
sleep "$(( RANDOM % 5 ))"
exit "$(( RANDOM % 2 ))"
}
for (( i = 0; i < 16; ++i )); do
(( jobs++ < max_jobs )) || wait_next
worker & job_by[$!]=
done
while (( ${#job_by[@]} )); do
wait_next
done
declare -p status_by
--
Kerin Millar
On Mon, 11 Mar 2024 11:45:17 -0400
Chet Ramey wrote:
> On 3/11/24 12:08 AM, Kerin Millar wrote:
>
> > Speaking of which, to do both of these things has some interesting effects
> > ...
> >
> > $ z() { local -g a; unset -v a; a=123; echo "innermost: $a&
g var" creates
> a variable at the global scope, any references to "var" within the
> function still use the standard dynamic scoping rules. They won't
> necessarily *see* the global variable, if there's another one at a
> more localized scope.
--
Kerin Millar
On Sun, 10 Mar 2024 16:01:10 -0400
Lawrence Velázquez wrote:
> On Sun, Mar 10, 2024, at 1:51 PM, Kerin Millar wrote:
> > Dynamic scoping can be tremendously confusing. The following examples
> > should help to clarify the present state of affairs.
> >
> > $ x(
outermost scope -
that which most would consider as being implied by the term, global - is duly
reached.
The manual states that the "-g option forces variables to be created or
modified at the global scope, even when declare is executed in a shell
function" and that "it is ignored in all other cases". I would consider this
wording insufficient for a user to be able to effectively reason with the
difference between the second case and the other two cases presented.
--
Kerin Millar
can be replaced with `grep -v -e
> BASH_VERSINFO -e PIPESTATUS -e GROUPS' though.
Indeed. This would be a perfectly sensible solution. For anything more
involved, there is always awk.
--
Kerin Millar
xpect for the manual to
describe it.
Note that quoting the left-hand side fixes it for SOH. In the absence of
quotes, xtrace output suggests that all of the SOH characters are stripped from
the expansion of $f$*$f.
$ ( set a -- b; f=$'\1' IFS=$f; [[ "$f$*$f" == *"$f--$f"* ]]; echo $? )
0
--
Kerin Millar
So, it expresses a preference for the last specified, mutually exclusive option
winning, _provided_ that it is documented to that effect. For that matter, +A
does not qualify as an option in their parlance.
In any case, it is a guideline, not an edict. It doesn't seem to me to be a
compelling argument against having the declare builtin treat an illogical
request as a usage error.
--
Kerin Millar
a null byte
>
Is this not merely adding a comment?
--
Kerin Millar
end. I would say this is a bug, but interaction between "set
> -
It isn't a bug. In this particular case, the exit status of echo was 0, while
the exit status of the false builtin was immaterial.
The behaviour of errexit can be confusing in practice. You may find
https://mywiki.wooledge.org/BashFAQ/105 to be an interesting read.
--
Kerin Millar
On Tue, 30 Jan 2024 10:34:28 -0500
Chet Ramey wrote:
> On 1/30/24 10:29 AM, Kerin Millar wrote:
>
> >>> I'm not sure that this is accurate. In my testing, bash does not even
> >>> perform this canonicalization step, which is optional to begin w
rd utilities have
a section of "1p".
https://repology.org/project/man-pages-posix/versions
--
Kerin Millar
On Tue, 30 Jan 2024 10:22:18 -0500
Chet Ramey wrote:
> On 1/28/24 10:34 AM, Kerin Millar wrote:
> > On Sun, 28 Jan 2024 18:09:24 +0300
> > Oğuz wrote:
> >
> >> On Sun, Jan 28, 2024 at 5:10 PM wrote:
> >>> POSIX Programmer's Manual (cd(1p) manpage)
On Mon, 29 Jan 2024 10:30:43 -0500
Chet Ramey wrote:
> On 1/29/24 5:51 AM, Kerin Millar wrote:
>
> > $ bash -c 'declare -p BASH_VERSION; cd ""'
> > shell-init: error retrieving current directory: getcwd: cannot access
> > parent directories: No
'
shell-init: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
declare -- BASH_VERSION="5.2.26(1)-release"
chdir: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
--
Kerin Millar
our of bash appears to conform with the wording of
Issue 7 but it may have to change for Issue 8 or a later revision.
--
Kerin Millar
er.
>
Related: https://austingroupbugs.net/view.php?id=1047
An associated issue is that there presently appears to be no way of suppressing
the processing of CDPATH in bash.
--
Kerin Millar
-forking command substitution syntax.
You would need to build bash from the devel branch to reproduce it.
--
Kerin Millar
t; bash: ./support/mkdep: No such file or directory
> make: *** [Makefile:978: depends] Error 127
>
>
>
> I do have a full log if you need/want it. I don't see mkdep anywhere in
> the build tree. Is this a "bug" or a mistake on my part?
As far as I can tell, it exists only in the devel branch. However, mkdep should
not be used - at least, not for GNU make. Which commands were issued on your
part?
--
Kerin Millar
On Sat, 16 Dec 2023 00:09:10 +
Kerin Millar wrote:
> At this point, the value of $? is 1, prior to executing true - a simple
> command. Just as for any other simple command, the trap code shall be
> executed beforehand. Consequently, your test observes that $? is
> arithmet
est observes that $? is arithmetically false
and acts accordingly. Keep in mind that this is the only part of your script in
which an "else" clause is actually reached.
> true
> fi
>
> debugoff
>
>
--
Kerin Millar
> > a system admin POV, on systems that have process managers.
> I am not super knowledgeable in this kind of stuff, but would that not
> cause you to lose your SSH connection?
It would not. Nor would even a restart, owing to the way privilege separation
is implemented in sshd(8).
--
Kerin Millar
ell?
>
> $(< file) does indeed fork. The only difference between $(< file) and
> $(cat file) is the latter also does an exec (but it's portable).
This stopped being the case with the release of 5.2 or thereabouts.
--
Kerin Millar
a way that does not involve
comsubs. Therefore, I would place a greater value on the elimination of
gratuitous comsubs, where possible, than to merely replace all of them with
funsubs (notwithstanding that 5.3 has yet to be released).
--
Kerin Millar
On Wed, 6 Dec 2023 05:43:43 +
Kerin Millar wrote:
> 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
> > O
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
: 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 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
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 ---
g 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
30 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
ting 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
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
> >
.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
ls 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
sages 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
nsider 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
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:
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:4
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, Vic
ipts, string-slicing parameter expansions etc
--
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
)
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 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
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
tf '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
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't &qu
uses it (nor should anybody wish to upon realising how it
works).
--
Kerin Millar
cts to be given a pipeline.
--
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: ‘D
LPAREN:
> + 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
ur for 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
>
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
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
th *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
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
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
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
ve 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
se arguments is -e, which is treated as an option.
--
Kerin Millar
ken 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
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 m
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 legiti
ar, 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
hould 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
On Thu, 29 Jun 2023 11:55:12 +0200
Sebastian Luhnburg wrote:
> #!/usr/bin/env bash
>
> initial_password="\$abc"
> echo "initial password: " $initial_password
> printf -v password '%q' $initial_password
> echo "initial password with escaped characters: " $password
> bash << EOF
> echo "password
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
y 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 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.2. Th
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 trick
ONEXISTENT
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 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
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:
> > >
1 - 100 of 152 matches
Mail list logo
