On Sat, May 18, 2024, at 11:17 AM, Phi Debian wrote:
> I am xing fingers the consensus, if any of theses takes off,
> is to have [...] protection against alias source='source -i'
This seems out of scope, regardless of what happens with "-i".
> I really depend on actual 'source' behavior, and
On Sat, May 18, 2024, at 11:41 AM, Matheus Afonso Martins Moreira wrote:
>> I am xing fingers the consensus, if any of theses takes off,
>> is to have the -i implemented (not omitted)
>
> Me too. Do you know anyone else who could be impacted?
> Consensus might move in that direction if more voices
The devel man page and texinfo manual both describe the upcoming
GLOBSORT variable with the following sentence, which has a stray
comma at the end. (I omitted it in my last message to kre.)
A sort specifier of `nosort' disables sorting completely;
the results are returned in the
On Thu, May 16, 2024, at 11:36 PM, Robert Elz wrote:
> Date:Thu, 16 May 2024 11:36:50 -0400
> From:Chet Ramey
> Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>
>
> | I have high hopes for `GLOBSORT', though.
>
> That is at least a plausible name - never
On Tue, May 14, 2024, at 3:51 PM, Chet Ramey wrote:
> On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote:
>> Passing the -i option to the source builtin
>> enables isolated sourcing mode which restricts
>> its search path to the directories defined by
>> the BASH_SOURCE_PATH variable. This
On Mon, May 6, 2024, at 1:27 AM, Matheus Afonso Martins Moreira wrote:
>> I fail to see how this could possibly save "thousands and thousands
>> of lines of code".
>
> How many lines of code were needed to implement the module managers?
> Probably a lot of lines. I guessed it was in the "thousands
On Sun, May 5, 2024, at 12:35 AM, Matheus Afonso Martins Moreira wrote:
> I agree that a one line of code reduction is underwhelming
> but that's not the only reason to include it. The users are the
> main beneficiaries. This gives users a simple way to load
> modules without using any module
On Sun, May 5, 2024, at 5:54 AM, Matheus Afonso Martins Moreira wrote:
> This patch set adds a special operating mode to the existing source
> builtin to make it behave in the desired way. When source is passed
> the options --library or -l, it will search for files in the
> directories given by
On Thu, May 2, 2024, at 9:40 PM, Dale R. Worley wrote:
> It seems like you could get much the same effect with this device:
>
> --
> t1 contains:
>
> # Where I am doing this testing.
> BASH_IMPORT_PATH=$HOME/temp/import/t2
>
>
On Thu, May 2, 2024, at 6:22 PM, Matheus Afonso Martins Moreira wrote:
> Bash scripts can be hard to get right so reusing proven solutions
> as shell script libraries is of immense value. However, the existing
> shell script sourcing mechanisms are suboptimal for this task.
> The source builtin
On Thu, May 2, 2024, at 6:22 PM, Matheus Afonso Martins Moreira wrote:
> The find_user_import function looks for executable scripts
> in a separate location meant for reusable libraries and modules,
> separate from other executables.
>
> Signed-off-by: Matheus Afonso Martins Moreira
> ---
>
On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote:
> I don't know why this savannah ticket has been crossposted to @bug-bash,
> but its replies have not been crossposted here: it is very confusing.
Apparently it's not possible to have the replies crossposted:
Both the manual [1] and man page [2] state:
The words between the [[ and ]] do not undergo word splitting
and filename expansion. The shell performs tilde expansion,
parameter and variable expansion, arithmetic expansion,
command substitution, process
On Mon, Apr 22, 2024, at 1:41 AM, Cedric Blancher wrote:
> The Solaris ksh93-integration version of ksh93 has a newgrp -c option
> (David Korn, Glenn Fowler and Roland Mainz did implement it), which
> works like ksh93/bash -c, and executes script under the requested
> group, and upon exiting
On Wed, Apr 10, 2024, at 11:07 PM, Martin D Kealey wrote:
> But ... oh look, it's mentioned in §2.10.2 (
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10_02
> ).
>
> I wonder when that was added, and why?
It's been there since at least POSIX.2-1992 [1]. At a
Reproducing my comment [1] for the list:
> On Apr 4, 2024, at 5:57 PM, Richard Waite wrote:
>
> Does variable expansion for here-documents occur in a subshell?
Sometimes. When a command requires forking (roughly speaking), its
redirections (not just here-documents) are processed after the
On Sun, Mar 31, 2024, at 8:47 PM, Martin D Kealey wrote:
> Most English speakers find "explanations of names" to be distractions
> rather than helping, so if you REALLY want to add this, can it please NOT
> be right next to the first use of the word "POSIX".
As the OP noted, the info/online
On Sun, Mar 24, 2024, at 11:01 PM, Dan Jacobson wrote:
> P.S., "\t%s" seems to have an extra space squeezed between them with
> bash: "\t %s",
> unless perhaps the spec says that %s always starts with a space.
The standard doesn't say that, so in native mode bash's `fc' is
indeed slightly
On Sun, Mar 24, 2024, at 8:54 PM, Dan Jacobson wrote:
> Yes, it omits the line numbers. But leaves the "^I " separators!
>
> $ fc -l 999 1000|cat -vt
> 999^I echo invite Nerbleson for dinner
> 1000^I echo and Snordsworth too
> $ fc -ln 999 1000|cat -vt
> ^I echo invite Nerbleson for dinner
> ^I
On Sun, Mar 24, 2024, at 2:56 PM, Greg Wooledge wrote:
> On Sun, Mar 24, 2024 at 01:04:38PM -0400, Zachary Santer wrote:
>> On Fri, Mar 22, 2024 at 11:23 AM Chet Ramey wrote:
>> >
>> > This is what you can do with @K.
>> >
>> > https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00119.html
>>
On Sun, Mar 24, 2024, at 1:40 AM, Dan Jacobson wrote:
> $ help history
> should mention how in the world one is supposed to just print the plain
> history,
> without any line numbers or time stamps.
fc -ln 1
--
vq
On Sat, Mar 23, 2024, at 11:34 AM, A4-Tacks wrote:
> Description:
> I am unable to use logical inversion operators in line
> arithmetic extensions, nor can I escape them, which is undoubtedly
> abnormal
>
> Repeat-By:
> ```bash
> $ ((!RANDOM))
> bash: !RANDOM: event not
On Fri, Mar 22, 2024, at 12:54 PM, Greg Wooledge wrote:
> Also, I don't see the lower-case k transformation in the man page.
It's at the end of the list:
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=f3b6bd1#n3525
--
vq
On Wed, Mar 20, 2024, at 7:11 AM, Zachary Santer wrote:
> On Wed, Mar 20, 2024 at 12:29 AM Lawrence Velázquez wrote:
>>
>> This isn't specific to ${var[@]@k}.
>>
>> $ kv1='a 1 b 2 c 3'
>> $ kv2=(a 1 b 2 c 3)
>> $ declare -A
On Tue, Mar 19, 2024, at 11:18 PM, Zachary Santer wrote:
> As such, I would expect that
> $ declare -A assoc_2=( "${assoc_1[@]@k}" )
> would create assoc_2 as a duplicate of assoc_1. However, we see that
> the entire expansion becomes the key for a single array element, with
> its value being the
On Mon, Mar 18, 2024, at 12:49 AM, Kerin Millar wrote:
> On Mon, 18 Mar 2024 06:30:49 +0200
> Oğuz wrote:
>
>> On Sunday, March 17, 2024, tpeplt wrote:
>> >
>> >The texinfo version of the bash manual is missing a description of
>> > the ‘shopt’ option ‘syslog_history’.
>> >
>>
>> That must
On Sun, Mar 10, 2024, at 5:36 PM, Greg Wooledge wrote:
> Here it is in action. "local -g" (or "declare -g") without an assignment
> in the same command definitely does things.
>
> hobbit:~$ f() { declare -g var; var=in_f; }
> hobbit:~$ unset -v var; f; declare -p var
> declare -- var="in_f"
This
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() { local a; y; echo "outer: $a"; }
> $ y() { local a; a=123; echo "inner: $a"; }
> $ x; echo "outermost:
On Mon, Feb 19, 2024, at 4:08 AM, Xiangyu Chen wrote:
> From: Xiangyu Chen
>
> The console ouput lots of egrep warning message, those message causes
> test case fail in diff stage.
On what system does this happen? The proposed changes might break the test
suite on some older systems.
--
vq
On Sun, Feb 18, 2024, at 5:03 PM, Kerin Millar wrote:
> Hi,
>
> This report stems from the discussion at
> https://lists.gnu.org/archive/html/help-bash/2024-02/msg00085.html.
>
> Consider the following two cases.
>
> $ ( set a -- b; f=+ IFS=$f; [[ $f$*$f == *"$f--$f"* ]]; echo $? )
> 0
>
> $ (
On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote:
> Recently, I discovered a potential bug in the 'bash --posix' terminal
> and I believe I have a fix that could resolve this issue. Before
> proceeding, I wanted to confirm if this is an open-source project where
> external contributions via
On Tue, Jan 16, 2024, at 4:43 PM, Chet Ramey wrote:
> On 1/9/24 11:23 PM, Martin D Kealey wrote:
>> The words “Integer constants follow the C language
>> definition, without suffixes or character constants” were not added to the
>> manual until June 2019 in the Devel branch (as commit
>>
On Fri, Jan 12, 2024, at 2:06 PM, Robert Elz wrote:
> ps: the use of process substitution there is just silly, it would work
> just as well, and be easier to understand if written:
>
> printf '\\\nabc' | { read -N1; read -r b c; }; declare -p REPLY b c
Presumably Greg was just preventing
On Sat, Dec 9, 2023, at 10:28 PM, Koichi Murase wrote:
> 2023年12月10日(日) 12:10 jidanni :
>> Maybe on the list of config files bash looks at,
>> there should be also .config/bash/... as that is
>
> There was a discussion:
>
> https://lists.gnu.org/archive/html/bug-bash/2021-05/threads.html#00024
>
On Tue, Nov 28, 2023, at 5:33 PM, Klaus Frank wrote:
> sorry, but this is not true
It is true.
> I can clearly see that it exists. It may be
> an distro addition though. Is it specific to ArchLinux? Because I can
> see it being used and when I try to use it on my system it also clearly
>
On Fri, Oct 27, 2023, at 12:25 AM, Grisha Levit wrote:
> On Thu, Oct 26, 2023, 20:30 Dale R. Worley wrote:
>
>> I suspect the difference between the versions is how the regexp is
>> unquoted while it is being read, with version 3 interpreting [^\'] as
>> "character class excluding newline,
On Thu, Oct 26, 2023, at 7:01 PM, Greg Wooledge wrote:
> On Thu, Oct 26, 2023 at 10:50:13AM -0700, Dan Bornstein wrote:
>> I found a case where the regex evaluator doesn't seem to be finding the
>> longest possible match for a given expression. The expression works as
>> expected on an older
On Tue, Oct 17, 2023, at 10:48 AM, Christoph Anton Mitterer wrote:
> As Lawrence pointed out:
> $ set -u
> $ declare -A a
> $ echo ${a[k]}
> bash: a[k]: unbound variable
>
> Here it actually looks first at a (which turns out to be an associative
> array) and thus doesn't even bother to evaluate
On Mon, Oct 16, 2023, at 9:06 PM, Christoph Anton Mitterer wrote:
> $ set -u
> $ [ -n "${array[key]+is_set}" ] && echo is set || echo not set
> bash: key: unbound variable
> $ [[ -v array[key] ]] && echo is set || echo not set
> bash: key: unbound variable
Since "array" has not been declared at
On Sun, Sep 3, 2023, at 6:08 AM, Dan Jacobson wrote:
> please either say
> + m=$@
> + n=($@)
> or better:
> + m='a b c'
> + n=('a' 'b' 'c')
> or metion on
> https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
> the special exception.
This behavior is not specific to $@.
On Wed, Aug 30, 2023, at 2:12 PM, Victor Pasko wrote:
> Attached please find bug.bash to reproduce incorrect BASH behaviour for
> BASH arrays
> and look at ways to run it
Your tests are flawed. The lines you use to inspect RESULT...
> badsed() { # just array indexes are used for RESULT
> ...
On Mon, Aug 14, 2023, at 1:27 AM, Eduardo Bustamante wrote:
> The echo command is consuming the '-e', as it is a flag. Instead, try
> using:
>
> printf '%s\n' "${x/,/ }"
Also note that echo wouldn't have consumed the "-e" had the expansions
been quoted properly (as Eduardo did in his printf
On Thu, Aug 10, 2023, at 2:21 PM, Dale R. Worley wrote:
> My understanding is that "interactive" directly affects only two things,
> the startup file(s) read and the initial values of various shell
> options.
There are more differences than that.
On Tue, Aug 8, 2023, at 12:04 PM, cirrus.mazurka-0t--- via Bug reports for the
GNU Bourne Again SHell wrote:
> The following code:
>
> ``` bash
> #!/usr/bin/env bash
>
> set -Eeuo pipefail
> shopt -s huponexit
> shopt -s inherit_errexit
>
> function child_function {
> return 1
> }
>
> On Jul 26, 2023, at 5:14 PM, tho...@habets.se wrote:
>
> On Wed, 26 Jul 2023 21:52:32 +0100, Dennis Williamson
> said:
>> You didn't include all the output. It's treated as a warning rather than an
>> error. That's why an error status isn't set.
>
> Ah indeed, the stderr message with bash
On Wed, Jul 19, 2023, at 9:31 AM, Beer, Mathis wrote:
> On Tue, Jul 18, 2023, at 20:58:50 CEST, Lawrence Velázquez wrote:
>> Presumably the synopses in all locations should also use this:
>>
>> -o [option-name]
>> +o [option-name]
>>
>> -
On Tue, Jul 18, 2023, at 9:29 AM, Beer, Mathis wrote:
> Add documentation for 'set -o', 'set +o' syntax to 'help set', 'info'.
> 'set -o'/'set +o' matches the POSIX behavior, but Bash's own documentation
> should also mention it.
> Phrasing is copied from the manpage, which already mentions it.
On Wed, Jul 5, 2023, at 9:01 PM, Wiley Young wrote:
> Here's some code as observed "in the wild:"
>
> `[[ ${#@} -ne 0 ]] && ...`
>
> Perhaps the parser is reading this as an incomplete parameter
> transformation? It seems from context that the original intent was simply...
>
> `[[ $# -ne 0 ]]
On Sun, Jul 2, 2023, at 8:30 PM, Dan Jacobson wrote:
> man page says:
>
>A variable may be assigned to by a statement of the form
>
> name=[value]
>
>If value is not given, the variable is assigned the null string. All
>values undergo tilde expansion,
On Sat, Jul 1, 2023, at 3:55 PM, Top Dawn wrote:
> I believe there is a bug with associative arrays, when once referenced in
> another function through the -n option, both the new reference name and the
> old one are made available.
>
> ```bash
>
> #!/bin/bash
> function my_function(){
>
On Tue, Jun 20, 2023, at 11:55 PM, LitHack wrote:
> Sorry instead of alias we have to use the function.
There is still no bug. You simply do not understand how the shell
language works.
(There's nothing wrong with that, of course, and questions are
welcome at . But your "bug reports" have all
On Tue, Jun 20, 2023, at 10:52 PM, LitHack wrote:
> -- Forwarded message -
> From: LitHack
> Date: Wed, Jun 21, 2023, 7:31 AM
> Subject: Command execution by creating file.
> To:
>
>
> Special character '*' can be used to execute the command.
> We have to just create a directory
> On Jun 16, 2023, at 11:39 PM, LitHack wrote:
>
> -- Forwarded message -
> From: LitHack
> Date: Sat, 17 Jun 2023 at 08:52
> Subject: Crashing the Linux System
> To:
>
>
> Running the yes command in command substitution will crash the linux shell.
> According to me inside
On Fri, Jun 16, 2023, at 1:02 AM, Wiley Young wrote:
> Description:
>`verb=(--) declare -ax verb` causes bash to crash and closes the active
> terminal tab.
The value "(--)" does not seem to be necessary:
% /bin/bash -c 'foo= declare -ax foo'
zsh: segmentation fault /bin/bash -c 'foo=
On Sat, Jun 3, 2023, at 12:40 AM, Budi wrote:
> Why the date command for time is incorrect and different from the
> correct one on panel bar
>
> $ date +%H
> 04
>
> $ date +%I
> 04
>
> while the correct is on panel bar which is 11 (real in 0..24 form, i.e. AM)
Given this...
> Date: Sat, 3 Jun
On Sat, Apr 1, 2023, at 9:27 PM, Kerin Millar wrote:
> On Sat, 1 Apr 2023 19:44:10 -0400
> Saint Michael wrote:
>
>> There is an additional problem with IFS and the command read
>>
>> Suppose I have variable $line with a string "a,b,c,d"
>> IFS=',' read -r x1 <<< $line
>> Bash will assign the
> On Apr 1, 2023, at 8:49 PM, Felipe Contreras
> wrote:
>
> On Sat, Apr 1, 2023 at 6:35 PM Lawrence Velázquez wrote:
>>
>> On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
>>> In that example they are discussing whether or not to make
On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
> In that example they are discussing whether or not to make that
> behavior a *requirement*. That is prescriptive.
You're so busy pretending this is debate club that you're completely
missing everyone's point, which is that the Austin
On Fri, Mar 31, 2023, at 2:10 PM, Chet Ramey wrote:
> kre filed an interpretation request to get the language cleaned up.
For those who might be interested:
https://austingroupbugs.net/view.php?id=1649
--
vq
On Thu, Mar 30, 2023, at 2:25 PM, Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 11:48 AM Oğuz İsmail Uysal
> wrote:
>>
>> On 3/30/23 7:51 PM, Felipe Contreras wrote:
>> > So? This is argumentum ad populum. The fact that most shells do X
>> > doesn't imply that POSIX says X.
>
>> POSIX
On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote:
> I see that Bash won't compile with a C23 compiler, since it still uses
> old-style function definitions which C23 no longer supports. Is there
> any effort and/or interest in fixing this portability problem in Bash?
I believe this was done
On Sun, Mar 5, 2023, at 1:33 AM, Syed Maaz wrote:
> Would you be so kind as to provide an update regarding my reported bug?
As previously mentioned, this mailing list is not responsible for
bash-hackers.org. Consider availing yourself of the contact form
on the website:
On Wed, Jan 25, 2023, at 6:37 PM, Sergei Trofimovich wrote:
> I fear it's a side-effect of the way 'bash' gets executed via shebang by
> kernel. But maybe not? Somehow direct script execution still manages to
> preserve script's name. Is it an intended behaviour that could not be
> easily changed?
On Tue, Dec 13, 2022, at 6:38 AM, Emanuele Torre wrote:
> On Tue, Dec 13, 2022 at 03:07:16AM -0500, Lawrence Velázquez wrote:
>> Of course not. I only meant to demonstrate that "export" always
>> creates global variables, so a function that utilizes "declare -gx&
On Mon, Dec 12, 2022, at 4:43 AM, L A Walsh wrote:
> On 2022/12/11 20:47, Lawrence Velázquez wrote:
>> This happens because "declare"/"typeset" creates local variables
>> within functions. Using -g works around this...
>>
>> $ Export()
On Sun, Dec 11, 2022, at 9:37 PM, L A Walsh wrote:
> I suppose one could create an alias (despite advice that
> functions are "better" -- in this case a function doesn't work).
> I'm using ':;' for PS1, so cut/paste works:
>
> PS1=':; '
>
> :; Export () {
> :; typeset -x "$@"
> :; }
> :;
On Mon, Dec 5, 2022, at 2:47 AM, Ulrich Windl wrote:
> So basically the behavior is as documented (not a bug), but the design
> decision was poor:
>
> declare a
> a=b
>
> has a different semantic as
> declare a=b
>
> which I consider to be bad.
You're free to think so, but this behavior is
On Tue, Nov 22, 2022, at 2:20 AM, Ulrich Windl wrote:
> AFAIK, bold means "literal" and non-bold or specifically italics means
> "placeholder".
> From man-pages(7):
>
> "(...) boldface is used for as-is text and italics are used to indicate
> replaceable arguments. Brackets ([]) surround
On Mon, Nov 21, 2022, at 4:38 AM, Ulrich Windl wrote:
> But from the syntax "${parameter:-word}" it's not really obvious that the
> colon may be omitted.
You're not wrong.
> Should it be "${parameter[:]-word}" (with non-bold square brackets) instead
> (as for "name=[value]")?
No, that would be
On Mon, Nov 21, 2022, at 2:20 AM, Ulrich Windl wrote:
> I think the bash manual page lacks some important detail of parameter
> substitution, namely:
> "Bash tests for a parameter that is unset or null. Omitting the colon
> results in a test only for a parameter that is unset."
>
> (found in
>
On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote:
> 2022年10月8日(土) 12:04 Cynthia Coan :
>> [...]
>>
>> Otherwise, I think we can perhaps reword this into two smaller
>> features: "function local trap signals",
>
> The existing RETURN trap is exactly the trap that can be used to clean
> up
On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> I'd specifically like to propose a new built-in called `defer` which
> acts like `eval` however is not parsed/expanded/run until it's scope
> is leaving. Hopefully "scope" is the correct word, I'm imagining it
> running at the same time a
On Sun, Aug 28, 2022, at 9:24 AM, Yair Lenga wrote:
> Wanted to get feedback about the following "extensions" to bash that will
> make it easier to work with simple JSON object.
It occurred to me to provide references for previous discussion
along these lines, but it turns out there isn't very
On Sun, Aug 28, 2022, at 4:05 PM, G. Branden Robinson wrote:
> At 2022-08-28T15:52:55-0400, Lawrence Velázquez wrote:
>> On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
>> > How about next July, when JSON is as exactly old as the Bourne shell
>> > was when
On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
> At 2022-08-28T14:11:25-0400, Lawrence Velázquez wrote:
>> I do not think bash needs to sprout functionality to support every
>> data-exchange format of the month.
>
> This sentiment is illustrative of the log
On Sun, Aug 28, 2022, at 2:29 PM, Yair Lenga wrote:
> I do not think that JSON (and REST) are "data exchange format of the
> month". Those are established formats that are here to stay. Like YAML.
> Those are "cornerstones" of cloud computing/configuration. I do not have to
> argue for them, they
On Sun, Aug 28, 2022, at 1:17 PM, Yair Lenga wrote:
> Yes, you are correct - (most/all of) of those examples "K".
>
> However, given bash's important role in modern computing - isn't it time to
> take advantage of new language features ?
Why? What benefit would that actually provide?
> this can
On Sun, Aug 28, 2022, at 9:24 AM, Yair Lenga wrote:
> Wanted to get feedback about the following "extensions" to bash that will
> make it easier to work with simple JSON object. To emphasize, the goal is
> NOT to "compete" with Python/Javascript (and other full scale language) -
> just to make it
On Sat, Aug 13, 2022, at 10:06 PM, Martin D Kealey wrote:
> I note that
> https://pubs.opengroup.org/onlinepubs/009696699/utilities/cut.html says:
> *> The elements in list can be repeated, can overlap, and can be specified
> in any order, but the bytes, characters, or fields selected shall be
>
On Fri, Aug 12, 2022, at 7:40 PM, Dennis Williamson wrote:
> It works for me. What are you expecting?
>
> It would help if you show what you're doing, the result you're getting and
> what you expect instead.
I'm guessing that instead of, for example
% bash -xc 'a="(x=1)" b="2*3";
On Fri, Jul 15, 2022, at 7:06 PM, Koichi Murase wrote:
> 2022年7月16日(土) 7:28 Lawrence Velázquez :
>> You can't shadow a readonly variable:
>>
>> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00152.html
>> https://lists.gnu.org/archive/html/bug-bash/201
On Fri, Jul 15, 2022, at 6:26 PM, Lawrence Velázquez wrote:
> it's worth noting that the trap command runs in the context
> from which the shell exits
Sorry, this might not be clear. Here I am referring to the command
that is provided as the argument to the "trap" utility.
&
On Fri, Jul 15, 2022, at 12:13 PM, Robert Stoll wrote:
> Following a script to reproduce the problem:
>
> =
>
> #!/usr/bin/env bash
> set -e
>
> function trapHook(){
> echo "$1"
> local -r
On Tue, Jul 5, 2022, at 8:09 PM, Yair Lenga wrote:
> My opinion is that we should be looking at the expected behavior - for
> a developer that want to implement ”strong” error handling: any error
> will break execution until explicitly handled. In the same spirit as
> the ‘try … catch’ that
On Tue, Jul 5, 2022, at 6:34 PM, Yair Lenga wrote:
> I probably did not described the intended behavior clearly. I believe
> both cases should behave identical under errfail. The loop will ‘break’
> on the first iteration (false when word = a). Same for the all looping
> commands. I believe
On Tue, Jul 5, 2022, at 5:18 PM, Yair Lenga wrote:
> I’m not in front of my desktop, so I can not verify behavior, but here
> is my expectation - let me know if it make sense, in the context of the
> project goal - every unhandled failed statement should unwind execution
> up, until explicitly
On Fri, Jul 1, 2022, at 4:07 AM, Vangelis Natsios wrote:
> When creating an alias containing a path ending with a non-latin (e.g.
> greek) directory name, a space character is appended to the end of the
> path, causing the alias to fail.
Not quite: Neither "paths" nor "non-Latin" characters are
On Tue, Jul 5, 2022, at 7:01 AM, Yair Lenga wrote:
> Below is the patch for the new 'errfail' option.
This doesn't apply cleanly to "devel". I assume you made it against
"master", which isn't the development branch -- "devel" is. Sorry
I forgot to mention that earlier.
--
vq
On Mon, Jul 4, 2022, at 3:55 PM, Yair Lenga wrote:
> I'm sorry - I misunderstood your original comments. I'll prepare the
> patched version (at least, I would like to add comments before
> publishing...) , and share it.
> Where/how can I post it ?
Send it to this list as an attachment [1] with a
On Mon, Jul 4, 2022, at 2:33 PM, Yair Lenga wrote:
> Thanks for taking the time to review my post. I do not want to start a
> thread about the problems with ERREXIT.
Neither do I.
> Instead, I'm trying to advocate for
> a minimal solution.
>
> [...]
>
> Please take a look at the specific short
On Mon, Jul 4, 2022, at 8:20 AM, Yair Lenga wrote:
> I was able to change Bash source and build a version that supports the new
> option 'errfail' (following the 'pipefail' naming), which will do the
> "right" thing in many cases - including the above - 'foo' will return 1,
> and will NOT proceed
On Mon, Jun 20, 2022, at 6:28 AM, n+b...@monade.li wrote:
> From: Naïm Favier
>
> Currently, typing `cmd flag1 flag2` (note the two spaces), navigating
> between the two spaces and hitting Tab produces
> `COMP_WORDS=(cmd flag1 flag2)` without inserting an empty word between
> flag1 and flag2.
>
On Fri, Jun 24, 2022, at 9:57 AM, Kerin Millar wrote:
> On Fri, 24 Jun 2022 13:53:07 +0200 (CEST)
> "Ing. Gerold Broser" via Bug reports for the GNU Bourne Again SHell
> wrote:
>
>> heredoc-error.sh:
>>
>> #!/bin/bash
>> sed -f - heredoc-error.sh <<-SCRIPT
>> ␣␣s/something/else/
>> ⭲
On Fri, Jun 10, 2022, at 10:19 AM, Chet Ramey wrote:
> I didn't look at more than mailx, but the description there makes it clear
> that $EDITOR needs to expand to a command name. `more' has similar wording
> ("The name of the editor shall be taken from the environment variable
> EDITOR.") and
On Thu, Jun 9, 2022, at 8:37 PM, Luciano wrote:
> By the way, git seems to interpret the EDITOR variable in a way
> consistent with C-x C-e, while the pass program as I said seems to just
> execute $EDITOR, like fc. I wonder if POSIX leaves room for
> interpretation here.
It does, insofar as it
On Sun, Jun 5, 2022, at 9:31 PM, Namikaze Minato wrote:
> @everyone, please let me know if I need to do something else to
> actually report the bug or if this thread is enough.
This thread is enough.
--
vq
On Fri, May 20, 2022, at 7:01 PM, Lawrence Velázquez wrote:
> On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
>> I'm going to tell him there is no guarantee that this can be changed.
>> For one thing, it would be difficult to find a letter that doesn't
>> tak
On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
> I'm going to tell him there is no guarantee that this can be changed.
> For one thing, it would be difficult to find a letter that doesn't
> take an unwanted meaning when associated with "word".
Perhaps something like "num" or
On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote:
> Should the "else" condition after the: || run if the last command in
> the: && section exits non zero?
Yes. This behavior is not a bug; ''A && B || C'' is simply not
equivalent to ''if A then B; else C; fi''.
> On Apr 24, 2022, at 3:41 PM, Oğuz wrote:
>
> 24 Nisan 2022 Pazar tarihinde Ángel yazdı:
>>
>> I think a shopt makes more sense. Forcing heredocs to be files although
>> something legit to request, is more a caller workaround to bugs in
>> called programs.
>>
>
>
1 - 100 of 224 matches
Mail list logo
