On Mär 31 2025, Chet Ramey wrote:
> It's hard to see these as being useful if they're glibc-specific.
They are coming from ISO TR 14652 and 30112.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely
On Mär 26 2025, Andreas Kähäri wrote:
> The argument to "bash -c"
There is no "bash -c" in that command.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
ve, for example, if one does
ENVIRON["LC_NUMERIC"] = "whatever"
in awk, while that should appear in the environment of something
awk runs for a system() operation, it doesn't affect the way awk
works, or its numeric input or output, any way at all.
| The shell d
On 3/29/25 4:52 PM, Lawrence Velázquez wrote:
Additional macro definitions, beginning with the characters
LC_ and an uppercase letter, may also be specified by the
implementation.
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/locale.h.html
Thank
On 3/31/25 12:52 PM, Andreas Schwab wrote:
On Mär 31 2025, Chet Ramey wrote:
It's hard to see these as being useful if they're glibc-specific.
They are coming from ISO TR 14652 and 30112.
OK. And when other systems support them, and they get standardized, it will
be time to revisit the issu
uot;LC_NUMERIC"] = "whatever"
in awk, while that should appear in the environment of something
awk runs for a system() operation, it doesn't affect the way awk
works, or its numeric input or output, any way at all.
| The shell does quite a lot of things that are different t
On Sat, Mar 29, 2025, at 4:52 PM, Lawrence Velázquez wrote:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/locale.h;hb=glibc-2.41#l33
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/langinfo.h;hb=glibc-2.41#l584
> https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/loca
On Sat, Mar 29, 2025, at 2:25 PM, Chet Ramey wrote:
> How does a locale doing this expose the category to the programmer?
> I suppose all possible additional locale categories have to be available
> to setlocale() somehow, via and the documentation.
Yeah, looks like POSIX explicitly permits that:
On 3/29/25 12:05 AM, Lawrence Velázquez wrote:
On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote:
On 3/26/25 6:29 PM, Robert Elz wrote:
LANG is generally just the fallback for categories that haven't been
set to something else. For this, assume the LC_ALL had never been
set (setting LANG aft
On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote:
> On 3/26/25 6:29 PM, Robert Elz wrote:
>> LANG is generally just the fallback for categories that haven't been
>> set to something else. For this, assume the LC_ALL had never been
>> set (setting LANG after that is set should probably just do n
On 3/26/25 6:29 PM, Robert Elz wrote:
Date:Wed, 26 Mar 2025 16:05:57 -0400
From:Chet Ramey
Message-ID:
| There is a precedence hierarchy associated with locale environment
| variables, since setting and unsetting environment variables is under
| the
with the rest of the variables
bash uses.
Thank you Chet and all the others who gave good clarifications. I was
just misled by the output of locale not always matching the environment
variables. Now I understand it clearly.
The bug was sitting in the chair in front of my computer. :)
--
Léa Gris
Date:Wed, 26 Mar 2025 16:05:57 -0400
From:Chet Ramey
Message-ID:
| There is a precedence hierarchy associated with locale environment
| variables, since setting and unsetting environment variables is under
| the user's control.
This brings up an unre
ence I sent.
Setting LC_ALL doesn't change LC_NUMERIC.
Environment variable: LC_NUMERIC=fr_FR.UTF-8
Setting LC_ALL=C actually switches the locale keys but not the
corresponding environment variables.
Correct. More precisely, LC_ALL has higher precedence than the other
LC_ environment var
On 3/26/25 8:09 AM, Léa Gris wrote:
I wonder if locale is switched accordingly to environment variables, but
environment variables may not automatically switch to the new locale.
There is a precedence hierarchy associated with locale environment
variables, since setting and unsetting
fr_FR.UTF-8).
I think you're misunderstanding the order of execution here.
This may not necessarily be a bug, but the behavior is counterintuitive and
inconsistent, making it difficult to predict how inline environment
variables will affect both variable expansion and command executi
On 3/26/25 7:54 AM, Andreas Kähäri wrote:
On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting
LC_ALL does not automagically set LC_NUMERIC in "bash -c":
% LC_ALL=C bash -c 'echo "$LC_NUMERIC"'
(blank line output)
% LANG=C bash -c 'echo "$LC_NUMERIC"'
t;
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
I wonder if locale is switched accordingly to environment variables, but
environment variables may not automatically switch to the new locale.
--
Léa Gris
On Wed, Mar 26, 2025 at 01:35:12PM +0100, Andreas Schwab wrote:
> On Mär 26 2025, Andreas Kähäri wrote:
>
> > The argument to "bash -c"
>
> There is no "bash -c" in that command.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3
_MESSAGES="C"
> LC_PAPER="C"
> LC_NAME="C"
> LC_ADDRESS="C"
> LC_TELEPHONE="C"
> LC_MEASUREMENT="C"
> LC_IDENTIFICATION="C"
> LC_ALL=C
>
>
> I wonder if locale is switched accordingly to environment variables
t;
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
Environment variable: LC_NUMERIC=fr_FR.UTF-8
Setting LC_ALL=C ac
ected. The reference to LC_NUMERIC is expanded before the
> command execution is started (which includes putting LC_NUMERIC=C in the
> temporary environment for the command).
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4
cludes putting LC_NUMERIC=C in the
temporary environment for the command).
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hello,
While experimenting with inline environment variables, I noticed that
although they are correctly applied to command execution, their
expansion sometimes retains the previous value—but not always!
Context:
Bash version: GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu
please .. how what .. ?
On Thu, Jan 9, 2025, 11:15 PM Wiley Young wrote:
> On Wed, 8 Jan 2025 08:44:06 +1000,
> Martin D Kealey wrote:
>
> > I invite anyone to provide an example of how
>
> If the documentation changes at all, I think just a "See also..." might be
> enough.
>
> Wuley
>
On Wed, 8 Jan 2025 08:44:06 +1000,
Martin D Kealey wrote:
> I invite anyone to provide an example of how
If the documentation changes at all, I think just a "See also..." might be
enough.
Wuley
On 1/7/25 11:53 PM, Oğuz wrote:
A reminder that options enabled by the set command are inherited by
child shells when SHELLOPTS is exported
A sentence saying this is reasonable, if redundant.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita br
On Wednesday, January 8, 2025, Martin D Kealey
wrote:
>
> SHELLOPTS (such as debugging or delinting), but if it has no safe
> production use then perhaps that should be highlighted in the
> documentation.
>
Nah. A reminder that options enabled by the set command are inherited by
child shells when
On Tue, 7 Jan 2025, 21:24 Tobi Laskowski, wrote:
> the issue starts with misusing SHELLOPTS.
Some folk have taken issue with my suggestion that SHELLOPTS is broken by
design. Perhaps that was hyperbole, but it seems to me that if all possible
uses for a feature actually constitute misuses, then
ill likely
find the SHELLOPTS documentation which says:
> If this variable is in the environment when Bash starts up, each shell option
> in the list will be enabled before reading any startup files.
This line gives the impression that using SHELLOPTS the way setup-ocaml is
using it is a r
> This precdence question is really the only one. Is this issue serious
> enough to change previous behavior in an incompatible way?
To me it seems most intuitive for flags to be applied after the environment
variable, but I do not mind too much about this.
> No. That is not consistent
On Jan 05 2025, Tobi Laskowski wrote:
> "It may be safe, however, it is a bit tedious...
Wow. I remember once I corrected an obvious flaw in a major project's CICD
bash scripts involving quoting and the trap builtin. You'd have thought I'd
have tried to chop somebody's fingers off.
Wiley
t tedious to such an extent where it seems
like it's a misuse of SHELLOPTS to try to pre-initialise as an environment
variable like this to enable an option.
On 1/5/25 6:17 AM, Tobi Laskowski wrote:
This does not cover the specific behaviour I am concerned with. I would expect
something like:
"Additionally, if it is in the environment at start up, the variable is
automatically exported and shell options enabled subsequently through other
On 1/4/25 2:47 PM, Tobi Laskowski wrote:
Hello,
I'd like to ask about an odd behaviour relating to the SHELLOPTS environment
variable. This is present in version 5.2.37(1)-release and in the development
version.
It's the behavior of every bash version going back to bash-2.0.
In
dence over the options specified in the
environment.
Maybe, but SHELLOPTS has never behaved like that.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
On 1/5/25 8:09 AM, Robert Elz wrote:
Date:Sun, 5 Jan 2025 11:17:05 +
From:Tobi Laskowski
Message-ID:
| It is not possible to have a naive SHELLOPTS=myopt configured outside
| the shell without all future options being exported implicitly.
I have neve
adding an environment variable that does the same
thing.
You can exactly duplicate the current set of options in a child shell
without having to mess around with startup files. I agree that cygwin
probably should have used BASH_ENV for their intended use.
--
``The lyf so short, the craft so lon
On 1/5/25 3:59 AM, Martin D Kealey wrote:
On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
This is documented in the manual:
In other words, it's broken by design.
You seem awfully sure of the correctness of your opinion.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
n the command-line arguments
> should take precedence over the options specified in the
> environment.
I agree with this, for whatever that's worth.
Date:Sun, 5 Jan 2025 11:17:05 +
From:Tobi Laskowski
Message-ID:
| It is not possible to have a naive SHELLOPTS=myopt configured outside
| the shell without all future options being exported implicitly.
I have never used SHELLOPTS, and have never tested this
On Jan 05 2025, Tobi Laskowski wrote:
> "Additionally, if it is in the environment at start up, the variable is
> automatically exported
That is a general property of every environment variable.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510
>> On the other hand, if there is a pre-existing SHELLOPTS environment variable
>> (set outside the current shell), then the `nounset` option applies to all
>> invocations of bash within the current shell.
> This is documented in the manual:
>> A colon-separated li
On Sunday, January 5, 2025, Martin D Kealey wrote:
>
> In other words, it's broken by design.
>
Maybe. I'm not sure if propagating shell options to child shells was the
intended primary use. With ENV/BASH_ENV you can already do that and more, I
don't see the point
2025年1月5日(日) 5:43 Tobi Laskowski :
> On the other hand, if there is a pre-existing SHELLOPTS environment
> variable (set outside the current shell), then the `nounset` option
> applies to all invocations of bash within the current shell.
This is documented as Oguz pointed out.
> E
At 2025-01-05T18:59:57+1000, Martin D Kealey wrote:
> On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
> > This is documented in the manual:
>
> In other words, it's broken by design.
Well, pull out of your back pocket what you've been coyly keeping from
us--a programming language that occupies global o
On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
> This is documented in the manual:
>
In other words, it's broken by design.
> Try BASH_ENV instead:
>
> https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fENV
>
Don't forget ENV as well, for sh scripts.
-Martin
On Saturday, January 4, 2025, Tobi Laskowski wrote:
>
> On the other hand, if there is a pre-existing SHELLOPTS environment
> variable (set outside the current shell), then the `nounset` option applies
> to all invocations of bash within the current shell.
This is documented in the
Hello,
I'd like to ask about an odd behaviour relating to the SHELLOPTS environment
variable. This is present in version 5.2.37(1)-release and in the development
version.
In this case, the `nounset` option is only applied to the current shell and not
to nested bash invocations:
>
URL:
<https://savannah.gnu.org/support/?25>
Summary: compgen does not complete paths starting with
environment variables when called indirectly
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Wed 25 Sep 2
On 5/22/23 8:36 AM, Emanuele Torre wrote:
Error messages for fatal error e.g. ${x?foo} or rovar=foo or
$x expanded with nounset, report an error message prefixed by the string
"environment:" instead of "scriptname:" (or "$0:").
Thanks for the report.
Error messages for fatal error e.g. ${x?foo} or rovar=foo or
$x expanded with nounset, report an error message prefixed by the string
"environment:" instead of "scriptname:" (or "$0:").
$ bash -c '${x?hi}' asd
asd: line 1: x: hi
$ bash -c
On 11/27/22 10:55 AM, felix wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux medium 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2
(2022-10-21) x86_64 GNU/Linux
Machine Type: x86_64-pc-
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux medium 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2
(2022-10-21) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Le
17, 2022, 17:53 Chet Ramey wrote:
>
> On 8/16/22 10:09 PM, b1431736...@163.com wrote:
>
> > Bash Version: 5.1
> > Patch Level: 16
> > Release Status: release
> >
> > Description:
> > excuse me, how can I join the custom environment variable into
>
> In general, if you want to have a particular environment variable set
> "all the time", you insert "export X=..." in one of your startup files.
> If you want it visible to everybody, you insert that in one of the
> system startup files. Depending on exactly
Sam writes:
> You probably want to edit /etc/ld.so.conf or /etc/ld.so.conf.d/* instead.
The overall concept is that you almost certainly don't want to modify
the bash source code (and thus executable) to do this.
In general, if you want to have a particular environment variable set
On 2022-08-17 at 10:09 +0800, b1431736...@163.com wrote:
> excuse me, how can I join the custom environment variable
> into the source code of Bash, and see this variable when execute env
You probably need to export the variable in .bash_profile or .bashrc
files. As Chet said, there
> On 18 Aug 2022, at 00:19, b1431736...@163.com wrote:
>
> Because I'm using Android, Android doesn't support #!/bin/sh and #!/bin/bash,
> there is a dynamic library that fixes it, so I want to automatically add
> LD_PRELOAD before starting bash to make this dynamic library work , I want to
>
re named ) then search for those, to see where they act
> and add a static prefix yours at a safe position and safe code
>
>
>
>
> On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote:
>
> On 8/16/22 10:09 PM, b1431736...@163.com wrote:
>
> > Bash Version: 5.1
> > Patch L
h Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> excuse me, how can I join the custom environment variable into the
> source code of Bash, and see this variable when execute env
What is it you want to do? You rarely need to add code to bash t
add a static prefix yours at a safe position and safe code
>
>
>> On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote:
>>
>>> On 8/16/22 10:09 PM, b1431736...@163.com wrote:
>>>
>>> > Bash Version: 5.1
>>> > Patch Level: 16
>>> > Release St
e where they act
and add a static prefix yours at a safe position and safe code
> On Wed, Aug 17, 2022, 17:53 Chet Ramey wrote:
>
>> On 8/16/22 10:09 PM, b1431736...@163.com wrote:
>>
>> > Bash Version: 5.1
>> > Patch Level: 16
>> > Release Status: relea
excuse me, how can I join the custom environment variable into the
> source code of Bash, and see this variable when execute env
What is it you want to do? You rarely need to add code to bash to do
something like that.
--
``The lyf so short, the craft so long to lerne.''
y wrote:
On 8/16/22 10:09 PM, b1431736...@163.com wrote:
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> excuse me, how can I join the custom environment variable into the
> source code of Bash, and see this variable when execute e
ption:
> > excuse me, how can I join the custom environment variable into
> the source code of Bash, and see this variable when execute env
>
> What is it you want to do? You rarely need to add code to bash to do
> something like that.
>
> --
> ``The lyf so
On 8/16/22 10:09 PM, b1431736...@163.com wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
excuse me, how can I join the custom environment variable into the
source code of Bash, and see this variable when execute env
What is it you want to do? You
Machine Type: aarch64-unknown-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
excuse me, how can I join the custom environment variable into the
source code of Bash, and see this variable when execute env
On Fri, Apr 9, 2021, at 4:51 PM, Eli Schwartz wrote:
> Are you ready to have your day truly spoiled? Fedora's package for the
> external program GNU which, provides this /etc/profile.d/ script
> (automatically injected into the environment of any interactive shell
> sessions onc
On 4/9/21 4:22 PM, Greg Wooledge wrote:
> On Fri, Apr 09, 2021 at 03:08:25PM -0400, Craig Andrews wrote:
>> Description:
>> With "set -u", invoking "which" results in the output of:
>> environment: line 1: _declare: unboundvariable
>>
On 4/9/21 3:08 PM, Craig Andrews wrote:
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
With "set -u", invoking "which" results in the output of:
environment: line 1: _declare: unboundvariable
That should not happen, and does no
On Fri, Apr 09, 2021 at 03:08:25PM -0400, Craig Andrews wrote:
> Description:
> With "set -u", invoking "which" results in the output of:
> environment: line 1: _declare: unboundvariable
> That should not happen, and does not happen, with prior v
On Sat, Apr 10, 2021 at 4:08 AM Craig Andrews wrote:
> Repeat-By:
> Run this shell script:
> #!/bin/bash
> set -u
> echo "$(which bash)"
Tested with vanilla bash 5.1.0 it works well with `/bin/bash` as
output. Maybe one of your builtins or external commands is
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
With "set -u", invoking "which" results in the output of:
environment: line 1: _declare: unboundvariable
That should not
On 7/13/19 1:31 PM, Travis Everett wrote:
> Bash Version: 5.0
> Patch Level: 7
> Release Status: release
>
> *Description:*
> I've noticed that a timezone explicitly set in the TZ environment variable
> can get cached (if any date-using command/builtin is run) and th
-apple-darwin17.7.0
Bash Version: 5.0
Patch Level: 7
Release Status: release
*Description:*
I've noticed that a timezone explicitly set in the TZ environment variable
can get cached (if any date-using command/builtin is run) and then show up
(at least) in dates produced by the printf builtin'
On 1/8/19 1:47 AM, Cuong Manh Le wrote:
> Hi,
>
> I'm not sure this a feature or bug, but:
>
> $ BASH_ARGV0=foo /usr/local/stow/bash/bin/bash -c 'echo "$0"'
> /usr/local/stow/bash/bin/bash
>
> I expect $0 set to foo instead.
Thanks for the suggestion. BASH_ARGV0 comes in as a feature s
Hi,
I'm not sure this a feature or bug, but:
$ BASH_ARGV0=foo /usr/local/stow/bash/bin/bash -c 'echo "$0"'
/usr/local/stow/bash/bin/bash
I expect $0 set to foo instead. In zsh:
$ ARGV0=foo zsh -c 'echo $0'
foo
Set BASH_ARGV0 after initialize the shell works as expected.
Config
On 12/9/18 1:28 AM, Grisha Levit wrote:
> When a nameref local to a higher function scope points to a variable in the
> temporary environment, that nameref (correctly, it seems) expands to the
> value
> of the target variable from the temporary environment. However, assignment
> t
When a nameref local to a higher function scope points to a variable in the
temporary environment, that nameref (correctly, it seems) expands to the
value
of the target variable from the temporary environment. However, assignment
to
the nameref modifies the variable from the higher scope
Got it, thanks for the info.
Thanks,
Fan
-Original Message-
From: Chet Ramey [mailto:chet.ra...@case.edu]
Sent: Wednesday, October 24, 2018 4:48 AM
To: Chen, Farrah ; bug-bash@gnu.org
Cc: chet.ra...@case.edu
Subject: Re: Environment variable "PS4" can not be passed to b
This is because you're doing it as root. Bash strips PS4 from the
> environment when started as root, as a security precaution.
That change came in in bash-4.3 (patch 48). His vendor probably patched
their version of bash-4.2 to do the same thing.
--
``The lyf so short, the craft so lo
On Tue, Oct 23, 2018 at 03:20:12PM +, Chen, Farrah wrote:
> But in Bash script, it cannot work, it keeps its original value:
> [root@fchen ~]# cat test.sh
> #!/usr/bin/bash
> echo $PS4
> echo $FAN
This is because you're doing it as root. Bash strips PS4 from the
environ
Hello,
I found a strange phenomenon, just as the subject, environment variable "PS4"
cannot be passed to bash script, but any other variable, even self-defined
variable can be passed to bash script.
My bash version is "GNU bash, version 4.2.46(2)-release
(x86_64-redhat
osix # within bash
>>>
>>> causes it to set the value of the $POSIXLY_CORRECT shell
>>> variable to "y" (if it was not already set)
>>
>> Yes. This behavior dates from early 1997. It was put in on request so users
>> could get a posix environ
RECT shell
> > variable to "y" (if it was not already set)
>
> Yes. This behavior dates from early 1997. It was put in on request so users
> could get a posix environment from the shell, since GNU utilities
> understand the POSIXLY_CORRECT variable. I could improve the docu
On 8/15/18 11:05 AM, Chet Ramey wrote:
>> causes it to set the value of the $POSIXLY_CORRECT shell
>> variable to "y" (if it was not already set)
>
> Yes. This behavior dates from early 1997. It was put in on request so users
> could get a posix environment from
n bash whether
> with
>
> - bash -o posix
> - sh
> - env SHELLOPTS=posix bash
> - set -o posix # within bash
>
> causes it to set the value of the $POSIXLY_CORRECT shell
> variable to "y" (if it was not already set)
Yes. This behavior dates from early 1997. It was put
IXLY_CORRECT ends up in the environment of all
commands started by that bash thereafter, which means they start
behaving differently.
IMO, bash's posix mode should only affect bash and its builtin
commands, not the other commands started within bash.
That a #! /bin/sh -a script should make a
On Thu, Jul 19, 2018 at 2:44 PM konsolebox wrote:
> On Wed, Jul 18, 2018 at 5:19 AM, Grisha Levit wrote:
> > $ set -u; unset var; f() { test -v 'var[0]'; echo $?; }; var[0]=X f
> > 0
> > -bash: var[0]: unbound variable
>
> I'm not getting this error. What version of bash are you using?
Sorry ab
On Wed, Jul 18, 2018 at 5:19 AM, Grisha Levit wrote:
> $ set -u; unset var; f() { test -v 'var[0]'; echo $?; }; var[0]=X f
> 0
> -bash: var[0]: unbound variable
I'm not getting this error. What version of bash are you using?
--
konsolebox
On 7/17/18 5:19 PM, Grisha Levit wrote:
> When there is a variable with a name that includes a subscript in the
> environment, test -v looks at that variable rather than an array with
> that subscript.
Even though bash needs to do a better job to segregate environment
variables with inva
output:
>
> declare -a v=([0]="Y")
> r:
> v:
>
> However, if we start bash with `v[0]' already in the environment, such as
> with:
>
> env 'v[0]=' $BASH
>
> The behavior changes, and the output is:
>
> decl
When there is a variable with a name that includes a subscript in the
environment, test -v looks at that variable rather than an array with
that subscript.
I just posted about two ways [1] [2] to create variables like
`var[0]=X' and if both of those methods are fixed than this report
mig
The following commands:
declare -n r=v[0]
v=(X); r=Y
declare -p ${!v*}
printf "%s: <%s>\n" "r" "$r" "v" "$v"
Will normally produce the following output:
declare -a v=([0]="Y")
r:
v:
However, if
t; shell function calls, but that was removed in the most recent update.
Thanks for the quick reply!
I followed the link in item 2 and there is:
If the command name is a special built-in utility, variable assignments
shall affect the current execution environment. Unless the set -a option is
sh
>
> ...internal shell command `set' propagates environment variable to the
> process its running:
>
> $ /bin/sh
> sh-4.4$ VARIABLE=value set -o noglob
> sh-4.4$ env | grep VARIABLE
> VARIABLE=value
> sh-4.4$
Posix requires this behavior, which dates back to
Hi,
when comparing strange behaviors of different shell implementations Tomas
Janousek found this bug
When using BASH as sh shell...
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jun 13 16:25 /bin/sh -> bash
...internal shell command `set' propagates environment variable to the proc
Robert Elz wrote:
> I will send one more reply on this topic - I am replying to this message
> as I agree with the change of Subject - this is off topic for this list,
> which is why I will not respond any further to messages about this here.
You are most enlightened and I will do the same with th
delving into altered realities, then I agree that almost
anything is possible, and in such a universe, any word can be defined to
mean whatever you want it to mean. That's all fine, but is hardly helpful
when we are operating with the normal environment in which we all work.
kre
1 - 100 of 255 matches
Mail list logo
