Re: Set command lists the shell variables and values, then lists other text (Script?)

On Sun, Jan 26, 2025, at 5:40 PM, Pete Edwards wrote: > The set command executed should list the shell variables and values, > which > it does, but it is followed by other text, which looks like script text > that has no purpose in the output expectred. The `set' built-in is do

Re: Set command lists the shell variables and values, then lists other text (Script?)

On Sun, Jan 26, 2025 at 17:40:35 -0500, Pete Edwards wrote: > The set command executed should list the shell variables and values, which > it does, but it is followed by other text, which looks like script text > that has no purpose in the output expectred. The "set" command s

Set command lists the shell variables and values, then lists other text (Script?)

I am seeing this issue on a new install of Windows 11 with Msys2 and VSCode installed The set command executed should list the shell variables and values, which it does, but it is followed by other text, which looks like script text that has no purpose in the output expectred. Please advise

Re: [Assignements to variables with integer attribute are expanded recursively]

x > Machine Type: x86_64-suse-linux-gnu > > Bash Version: 5.2 > Patch Level: 37 > Release Status: release > > Description: > [Assignments to variables with attribute 'integer' behave unexpectedly > if the right side has not an integer value. > It se

[Assignements to variables with integer attribute are expanded recursively]

inux pluto 6.12.8-1-default #1 SMP PREEMPT_DYNAMIC Thu Jan 2 12:47:33 UTC 2025 (ab2dfe6) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 5.2 Patch Level: 37 Release Status: release Description: [Assignments to variables with attribute 'integer'

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/18/24 12:55 AM, Martin D Kealey wrote: On Sun, 17 Nov 2024, 03:32 Chet Ramey, > wrote: On 11/16/24 3:36 AM, Martin D Kealey wrote: I don't think a disclaimer saying "this manual is not what it does not claim to be" is particularly useful. That's

Re: [bug #66455] declare -p [varname] does not recognize nameref variables

On Mon, Nov 18, 2024 at 07:39:31 -0500, Dominik Kummer wrote: > <https://savannah.gnu.org/bugs/?66455> > > Summary: declare -p [varname] does not recognize nameref > variables Hmm? hobbit:~$ declare -n ref=HOME hobbit:~$ declare -p ref declare -n ref="HOME"

[bug #66455] declare -p [varname] does not recognize nameref variables

URL: <https://savannah.gnu.org/bugs/?66455> Summary: declare -p [varname] does not recognize nameref variables Group: The GNU Bourne-Again SHell Submitter: domson Submitted: Mon 18 Nov 2024 01:39:22

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Monday, November 18, 2024, Martin D Kealey wrote: > > That's valid, but how else do we get people to read the correct document > for their skill level, How is it our responsibility? > I've used Bash for about 30 years, and even I have to wonder whether the > Shell manual should start with t

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Sun, 17 Nov 2024, 03:32 Chet Ramey, wrote: > On 11/16/24 3:36 AM, Martin D Kealey wrote: > I don't think a disclaimer saying "this manual is not what it does not > claim to be" is particularly useful. > That's valid, but how else do we get people to read the correct document for their skill l

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/16/24 3:36 AM, Martin D Kealey wrote: (Insert this between the "Copyright" and "Description" sections) I don't think a disclaimer saying "this manual is not what it does not claim to be" is particularly useful. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Sat, 16 Nov 2024 at 15:01, Robert Elz wrote: > Date:Sat, 16 Nov 2024 14:05:17 +1000 > From:Martin D Kealey > Message-ID: d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com> > > | I know, but "explicitly" is not the same as "highlighted", let alone > "well > | enough".

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Saturday, November 16, 2024, Martin D Kealey wrote: > (Insert this between the "Copyright" and "Description" sections) > > > *“PrefaceDear reader, if this is your introduction to the Shell programming > language, please be aware that although it may look like other languages > you are familiar

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Date:Sat, 16 Nov 2024 14:05:17 +1000 From:Martin D Kealey Message-ID: | I know, but "explicitly" is not the same as "highlighted", let alone "well | enough". Please, nothing at all like you're suggesting. Man pages are not, and not intended to be, tutorials.

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Fri, 15 Nov 2024 at 00:20, Chet Ramey wrote: > On 11/13/24 11:40 PM, Martin D Kealey wrote: > > > The fact that pipeline components are implicitly run in subshells is > > arguably not highlighted well enough [...] > > The man page states that explicitly. > I know, but "explicitly" is not th

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

aidd , thxx .. ++ On Thu, Nov 14, 2024, 8:45 PM Chet Ramey wrote: > On 11/14/24 2:28 PM, #!microsuxx wrote: > > maybe set -a 'd help ? > > if it can backwards export the vars > > No. A child process can't affect its parent's environment without inventing > some kind of IPC. > > -- > ``The lyf so

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/14/24 2:28 PM, #!microsuxx wrote: maybe set -a 'd help ? if it can backwards export the vars No. A child process can't affect its parent's environment without inventing some kind of IPC. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita bre

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

maybe set -a 'd help ? if it can backwards export the vars On Thu, Nov 14, 2024, 3:01 PM Chet Ramey wrote: > On 11/13/24 4:48 PM, Yuri wrote: > > > The first 'source' command didn't set variables set or exported in the > > child.sh script, even thou

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/13/24 11:40 PM, Martin D Kealey wrote: The fact that pipeline components are implicitly run in subshells is arguably not highlighted well enough, but it IS stated that all components of a pipeline run in parallel, so it is logically deducible that this must involve separate processes. Th

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/13/24 5:12 PM, Yuri wrote: On 11/13/24 14:02, Greg Wooledge wrote: The commands within a pipeline are executed in subshells (child processes), so all variable changes are discarded when the subshell exits. This sounds like an implementation detail that should be invisible that affects

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/13/24 4:48 PM, Yuri wrote: The first 'source' command didn't set variables set or exported in the child.sh script, even though 'source' is executed in the current script's context, The `source' command isn't "executed in the current sc

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Hi Martin, On 11/13/24 20:40, Martin D Kealey wrote: If you need to separate the output of `set -x` from your script's other output, consider setting BASH_XTRACEFD: exec 3>> /path/to/xtrace-logfile.txt BASH_XTRACEFD=3 set -x source your_file set +x exec 3>&- I didn't know about BASH_XTRACEF

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

The disappearance of the variables that you export within your sourced file is not a feature of the source command. That will happen to ANY command that changes the shell's internal state, when run in a subshell. The fact that pipeline components are implicitly run in subshells is arguabl

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Date:Thu, 14 Nov 2024 00:30:32 +0100 From:"#!microsuxx" Message-ID: | i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to | tty , or restore from saved Assuming that this is even slightly relevant to the question here (whether any of thi

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

another code is if u wanna not use . or eval or bash cmd ( . is source ) shopt -s expand_aliases alias script=" $( < user.bash ) " script On Thu, Nov 14, 2024, 1:10 AM #!microsuxx wrote: > also u need to $log > may i ask what criteria ur scripts are about > > a $log can be > > log=/tmp/my.log.

The 'source x' command doesn't keep variables set by x when source output is piped into other command

.sh echo "XVAR=$XVAR" echo "YVAR=$YVAR" prints this: XVAR= YVAR= XVAR=xx YVAR=yy The first 'source' command didn't set variables set or exported in the child.sh script, even though 'source' is executed in the current script's context, and i

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 15:56:57 -0800, Yuri wrote: > On 11/13/24 15:44, Greg Wooledge wrote: > > If the "user script" runs quickly enough, then: source userscript > > >logfile 2>&1 cat logfile > > > This would fail to save the user script's output in case it would execute > "exit 1" Then don't

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Yuri > Message-ID: > > | I need to (1) source the user script, (2) save this script's output to > a > | dedicated file, (3) keep the same output in stdout, and (4) keep > | environment variables that the user script sets for later commands. > | It doesn

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Date:Wed, 13 Nov 2024 15:18:58 -0800 From:Yuri Message-ID: | I need to (1) source the user script, (2) save this script's output to a | dedicated file, (3) keep the same output in stdout, and (4) keep | environment variables that the user script set

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

also u need to $log may i ask what criteria ur scripts are about a $log can be log=/tmp/my.log.$USER.$SRANDOM On Thu, Nov 14, 2024, 1:04 AM #!microsuxx wrote: > maybe ur email formats it wrong > those are two lines , by greg > not one > > anyway if u append more than one cmd to logfile > more

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

maybe ur email formats it wrong those are two lines , by greg not one anyway if u append more than one cmd to logfile more than one source cmd u need to use >>logfile instead of >logfile On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote: > > > On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: > >> On 1

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: > On 11/13/24 15:44, Greg Wooledge wrote: > > If the "user script" runs quickly enough, then: source userscript > > >logfile 2>&1 cat logfile > > > This would fail to save the user script's output in case it would > execute "exit 1" > the >logfile makes

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 15:18:58 -0800, Yuri wrote: > I need to (1) source the user script, (2) save this script's output to a > dedicated file, (3) keep the same output in stdout, and (4) keep environment > variables that the user script sets for later commands. If the "user s

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

t of the user script into a dedicated log >> file. >> This script should run, should save its output into a dedicated log, and >> then many other commands should use these environment variables. >> >> Their logs can't be combined into one. >> >> >>

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/13/24 15:44, Greg Wooledge wrote: If the "user script" runs quickly enough, then: source userscript >logfile 2>&1 cat logfile This would fail to save the user script's output in case it would execute "exit 1" Yuri

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

wrote: > Hi !microsuxx, > > > But I need to save the output of the user script into a dedicated log file. > This script should run, should save its output into a dedicated log, and > then many other commands should use these environment variables. > > Their logs ca

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

Hi !microsuxx, But I need to save the output of the user script into a dedicated log file. This script should run, should save its output into a dedicated log, and then many other commands should use these environment variables. Their logs can't be combined into one. Yuri On 11/13/

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

wrote: > >> On 11/13/24 14:48, #!microsuxx wrote: >> > 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd >> > tee < <( . foo ; cmds ) >> >> >> I need to (1) source the user script, (2) save this script's output to a >>

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

ipt, (2) save this script's output to a > dedicated file, (3) keep the same output in stdout, and (4) keep > environment variables that the user script sets for later commands. > It doesn't look like any of the above 3 lines do all these 4 requirements. > > > Yuri > > > >

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

>> The original code in my project runs 'source x.sh > log' where x.sh is >> some user-provided script. >> >> I wanted to trace the code using 'set -x' in order to report errors >> locations in scripts to the user. >> However, the trace al

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

environment variables that the user script sets for later commands. It doesn't look like any of the above 3 lines do all these 4 requirements. Yuri

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

goes to log instead of stdout. > When I changed that to 'source x.sh | tee log' - environment variables > that the user script x.sh also sets disappeared due to the problem in > SUBJECT. > > > This problem makes it very inconvenient to implement features around > scripts using 'source'. > > > > Yuri > > > >

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

eg in ur puroose u dont need source and in ur code when u understood | othercmd is in another subshell , u see it doesnt well if u pipe to tee , .. well the scope of needed 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd tee < <( . foo ; cmds ) On Wed, Nov 13, 2024, 11:45 PM

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

et -x' in order to report errors locations in scripts to the user. However, the trace also goes to log instead of stdout. When I changed that to 'source x.sh | tee log' - environment variables that the user script x.sh also sets disappeared due to the problem in SUBJECT. This p

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

depending on actual purpose instead bs demo code , there are serval approaches to code running code On Wed, Nov 13, 2024, 11:13 PM Yuri wrote: > On 11/13/24 14:02, Greg Wooledge wrote: > > The commands within a pipeline are executed in subshells (child > > processes), so all variable changes are

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On 11/13/24 14:02, Greg Wooledge wrote: The commands within a pipeline are executed in subshells (child processes), so all variable changes are discarded when the subshell exits. This sounds like an implementation detail that should be invisible that affects how the 'source' feature works. T

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 13:48:18 -0800, Yuri wrote: > # source is piped into tee > source child.sh | tee /dev/null > echo "XVAR=$XVAR" > echo "YVAR=$YVAR" > > # source is un-piped > source child.sh > echo "XVAR=$XVAR" > echo "YVAR=$Y

Re: [PATCH] Makefile: avoid undefined variables

On 10/26/24 5:04 PM, Mike Jonkmans wrote: On Thu, Oct 24, 2024 at 03:07:46PM -0400, Grisha Levit wrote: These are reported by make --warn-undefined-variables. Most were being set previously (sometimes 20 years ago) and got left behind in recepies after their definitions have been removed

Re: [PATCH] Makefile: avoid undefined variables

On Thu, Oct 24, 2024 at 03:07:46PM -0400, Grisha Levit wrote: > These are reported by make --warn-undefined-variables. > > Most were being set previously (sometimes 20 years ago) and got left > behind in recepies after their definitions have been removed. Others > only

Re: [PATCH] Makefile: avoid undefined variables

go through some of them. ALLOC_ABSSRC = ${topdir}/$(ALLOC_LIBDIR) There are ABSSRC and SRC variables for all the subdirectories. EXTRASOURCES = *(a long list)* This is from gettext. GCC_LINT_CFLAGS = $(BASE_CCFLAGS) $(CPPFLAGS) $(GCC_LINT_FLAGS) `make lint'

Re: [PATCH] Makefile: avoid undefined variables

On 10/26/24 10:32 AM, Martin D Kealey wrote: On Sat, 26 Oct 2024, 00:05 Dmitry Goncharov, wrote: - cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR) top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F) It is really not a good idea to pass makeflags on the command line as a positional pa

Re: [PATCH] Makefile: avoid undefined variables

On Sat, 26 Oct 2024, 00:05 Dmitry Goncharov, wrote: > >- cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR) > >top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F) > > It is really not a good idea to pass makeflags on the command line as a > positional parameter. Agreed, but I was just copy

Re: [PATCH] Makefile: avoid undefined variables

On 10/24/24 3:07 PM, Grisha Levit wrote: These are reported by make --warn-undefined-variables. Most were being set previously (sometimes 20 years ago) and got left behind in recepies after their definitions have been removed. Others only get set in some configurations so it makes sense to

Re: [PATCH] Makefile: avoid undefined variables

>- cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR) >top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F) It is really not a good idea to pass makeflags on the command line as a positional parameter. A variable (any variable, including makeflags) set on the command line, overrides the value

Re: [PATCH] Makefile: avoid undefined variables

On Fri, 25 Oct 2024 at 05:07, Grisha Levit wrote: > These are reported by make --warn-undefined-variables. > > Most were being set previously (sometimes 20 years ago) and got left > behind in recepies after their definitions have been removed. Others > only get set in some confi

[PATCH] Makefile: avoid undefined variables

These are reported by make --warn-undefined-variables. Most were being set previously (sometimes 20 years ago) and got left behind in recepies after their definitions have been removed. Others only get set in some configurations so it makes sense to prevent them from inheriting stray values from

[sr #111125] compgen does not complete paths starting with environment variables when called indirectly

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

Re: [PATCH v2 7/8] variables: define default BASH_SOURCE_PATH

On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: Define a build time configurable default value for the new BASH_SOURCE_PATH variable. Look for libraries in the user's home directory as well as the system wide directories. I don't like bash providing a default for this when bash doesn'

[PATCH v2 7/8] variables: define default BASH_SOURCE_PATH

Define a build time configurable default value for the new BASH_SOURCE_PATH variable. Look for libraries in the user's home directory as well as the system wide directories. Signed-off-by: Matheus Afonso Martins Moreira --- config-top.h | 7 +++ variables.c | 1 + 2 files changed, 8 inserti

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

ctory. As mentioned above, it's useful but there is an issue of the chicken or the egg. The user sets values to the variables in the shell, but the shell wants to know the value of the variables to initialize it on its startup. Some alternative ways are proposed, but a clean way hasn't y

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

t files intended to be sourced. You are mixing the > script file with the loadable builtins while trying to separate the > script files from the executable files. The same issue will arise in > another place. I agree. This will be revised. > This is the same as the argument for t

Re: [PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

y. > > XDG does not specify the ~/.local and ~/.local/lib directories. > Only the XDG Data Directory defaults to ~/.local/share if unset. > That implies a ~/.local directory tree that mirrors that of /usr. This is the same as the argument for the long option. Why only BASH_LIBRARIES_PATH (among

[PATCH 9/9] variables: define default BASH_LIBRARIES_PATH

Define a build time configurable default value for the new BASH_LIBRARIES_PATH variable. Look for libraries in the user's home directory as well as the system wide directories. Signed-off-by: Matheus Afonso Martins Moreira --- config-top.h | 7 +++ variables.c | 1 + 2 files changed, 8 inse

Bug#973620: bash: overflow on integer variables greater than 9223372036854775807

Control: found -1 5.2.21-2 Control: tags -1 upstream X-Debbugs-CC: bug-bash@gnu.org On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote: Dear Maintainer, recently while I was running some tests, I ran into this strange overflow: $ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$

Re: A feature request regarding redirection to variables

On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote: > > A very common thing I need to do when writing bash is to collect both > the stdout and stderr of a command. This can be done relatively > reasonably with files but it would be very attractive to be able to > redirect these directly to a variable

A feature request regarding redirection to variables

where "stdout" and "stderr" here are variables. This or equivalent would be very nice. currently I find myself reusing this pattern over and over: err_file="$(mktemp)" var_stdout="$(cmd 2>"$err_file)" exit_code=$? var_stderr="$(<"$err_file&

Re: Some Readline variables are not available in "bind -v"

On 7/16/23 9:25 AM, Sebastian Carlos wrote: Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color Thanks for the report. These two variables aren't reported by `bind -v' if they have a value, so th

Some Readline variables are not available in "bind -v"

Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color - isearch-terminators Thanks for your time.

Re: Bash silently exits where attempting to assign an array to certain built-in variables using declare

or. I'll look at how compound assignments are different. > > I have reconsidered this. Making assignments that are supposed to be > ignored set $? to 1 means that a shell with errexit enabled will exit. > I don't think that's desirable. I don't think attempted assignments to

Re: Bash silently exits where attempting to assign an array to certain built-in variables using declare

ments that are supposed to be ignored set $? to 1 means that a shell with errexit enabled will exit. I don't think that's desirable. I don't think attempted assignments to noassign variables should change $?. Chet -- ``The lyf so short, the craft so long to lerne.'' - C

Re: Bash silently exits where attempting to assign an array to certain built-in variables using declare

to assign an array to any of the following variables with the declare builtin causes bash to immediately exit with no diagnostic message being issued. BASH_ARGC BASH_ARGV BASH_LINENO BASH_SOURCE GROUPS These are all `noassign' variables; assignments to them are ignored

Re: Bash silently exits where attempting to assign an array to certain built-in variables using declare

g to assign an array to any of the following variables with the > > declare builtin causes bash to immediately exit with no diagnostic message > > being issued. > > > >BASH_ARGC > >BASH_ARGV > >BASH_LINENO > >BASH_SOURCE > >GROU

Re: Bash silently exits where attempting to assign an array to certain built-in variables using declare

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. Attempting to assign an array to any of the following variables with the declare builtin causes bash to

Bash silently exits where attempting to assign an array to certain built-in variables using declare

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. Attempting to assign an array to any of the following variables with the declare builtin causes bash to immediately exit with no diagnostic message

Re: Localised variables become exposed to environment when FUNCNEST reached

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-

Localised variables become exposed to environment when FUNCNEST reached

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

Re: ${var@A} expands to empty string for unset, but declared variables with no attributes

On 4/6/22 9:50 PM, Emanuele Torre wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: `${var@A}' only expands to something if either var is set or is declared with attributes; it doesn't expand to `declare -- var' for var

${var@A} expands to empty string for unset, but declared variables with no attributes

us: release Description: `${var@A}' only expands to something if either var is set or is declared with attributes; it doesn't expand to `declare -- var' for variables that are declared but don't have any attribute and are unset. Sh

Re: a nameref may resolve to different variables in assignment and parameter expansion

On 1/6/22 1:31 PM, Mark March wrote: It appears that the same initialized nameref variable may refer to variables in different scopes depending on the context where it is used. When used in an assignment, a nameref will look for the variable it references starting at the scope where the

a nameref may resolve to different variables in assignment and parameter expansion

It appears that the same initialized nameref variable may refer to variables in different scopes depending on the context where it is used. When used in an assignment, a nameref will look for the variable it references starting at the scope where the nameref itself was found, which may be below

Re: Tab auto-completion removes quotes from variables even when it shouldn't

fficial mirror: > > https://github.com/bminor/bash so I guess it's still a problem. > > > > Tab auto-completion removes quotes from variables even when it shouldn't. > > Thanks for the report. This is a known issue for which I haven't decided on > an acceptable

Re: Tab auto-completion removes quotes from variables even when it shouldn't

On 6/25/21 10:53 AM, Pedro Gimeno wrote: Bash Version: 4.4 Patch Level: 12 Release Status: release Tested also in the last version from this unofficial mirror: https://github.com/bminor/bash so I guess it's still a problem. Tab auto-completion removes quotes from variables even wh

Tab auto-completion removes quotes from variables even when it shouldn't

Bash Version: 4.4 Patch Level: 12 Release Status: release Tested also in the last version from this unofficial mirror: https://github.com/bminor/bash so I guess it's still a problem. Tab auto-completion removes quotes from variables even when it shouldn't. Test case: $ mkdir '

Re: Problem with sequences with variables?

On Wed, Apr 28, 2021 at 11:02:31PM +, Tom (AST) Watson via Bug reports for the GNU Bourne Again SHell wrote: > Hi... > > [user@box3 ~]$ echo $l > 10 > [user@box3 ~]$ echo {1..${l}} > {1..10} https://mywiki.wooledge.org/BashPitfalls#pf33

Re: Problem with sequences with variables?

On 4/28/21 7:02 PM, Tom (AST) Watson via Bug reports for the GNU Bourne Again SHell wrote: Hi... I was trying to do some sequences, and it looks like they don't like variables. See the following: Brace expansion happens first, before any of the other word expansions, so it requires in

Problem with sequences with variables?

Hi... I was trying to do some sequences, and it looks like they don't like variables. See the following: [user@box3 ~]$ echo $BASH_VERSION 5.0.17(1)-release [user@box3 ~]$ echo {1..10} 1 2 3 4 5 6 7 8 9 10 [user@box3 ~]$ echo $l 10 [user@box3 ~]$ echo {1..${l}} {1..10} [user@box3 ~]$ Shou

Re: Assign read-only variables return code not usable inline

On 2/23/21 7:54 AM, Léa Gris wrote: https://ideone.com/iw2pSv #!/usr/bin/env bash declare -r r r=2 || exit 2 OK, let's pick this one. This is what POSIX calls a "variable assignment error" in https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01 (you've om

Re: Assign read-only variables return code not usable inline

23 Şubat 2021 Salı tarihinde Léa Gris yazdı: > https://ideone.com/iw2pSv > > #!/usr/bin/env bash >> declare -r r >> r=2 || exit 2 > > There is no command substitution in `r=2', it will either succeed and return zero, or fail and cause the shell to discard the whole command (`r=2 || exit 2'); `e

Assign read-only variables return code not usable inline

https://ideone.com/iw2pSv #!/usr/bin/env bash declare -r r r=2 || exit 2 echo 'still there with $?='$?', after: r=2 || exit 2' if ! r='hello'; then exit; fi echo "still there with \$?=$?, after: if ! r='hello'; then exit; fi" typeset -p r Output: still there with $?=1, after: r=2

Re: bind documentation needs example for variables too, not just keys

On 1/7/21 1:58 AM, 積丹尼 Dan Jacobson wrote: Man bash says Readline Variables Readline has variables that can be used to further customize its behav‐ ior. A variable may be set in the inputrc file with a statement of the form set variable-name value

bind documentation needs example for variables too, not just keys

Man bash says Readline Variables Readline has variables that can be used to further customize its behav‐ ior. A variable may be set in the inputrc file with a statement of the form set variable-name value or using the bind builtin command (see SHELL

Re: Variables declared in arithmetic expressions have no i flag

On 11/24/20 8:30 AM, Léa Gris wrote: > Should variables automatically created within arithmetic constructs have > the integer flag implied? No. There's no reason to do this. If you want an integer variable, declare it as such beforehand. -- ``The lyf so short, the craft so lo

Re: Variables declared in arithmetic expressions have no i flag

On Tue, Nov 24, 2020 at 02:30:36PM +0100, Léa Gris wrote: > Should variables automatically created within arithmetic constructs have the > integer flag implied? No. Please, no. It's bad enough that the -i flag exists in the first place, without it being randomly added to poor innocen

Variables declared in arithmetic expressions have no i flag

Should variables automatically created within arithmetic constructs have the integer flag implied? unset x; ((x = 42)); typeset -p x > declare -- x="42" Should it be: declare -i x="42" Here are cases where that would make a difference: unset x; ((x = 42)); x+=624;

Re: Confusing documentation of `ENV` in section "Bash variables"

On Wed, 23 Sep 2020 at 14:24, Chet Ramey wrote: > "Expanded and executed similarly to BASH_ENV when an interactive shell is > invoked in POSIX Mode." > Yes, that's better than my suggestions, thanks! -- https://rrt.sc3d.org

Re: Confusing documentation of `ENV` in section "Bash variables"

On 9/22/20 6:27 PM, Reuben Thomas via Bug reports for the GNU Bourne Again SHell wrote: > The documentation says: > > 'ENV' > Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode > (*note Bash POSIX Mode::). Hmmm, I can see that. How about, as you suggest, something like

Confusing documentation of `ENV` in section "Bash variables"

The documentation says: 'ENV' Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode (*note Bash POSIX Mode::). However, as described elsewhere in the manual, BASH_ENV is used specifically for non-interactive shells, whereas ENV is used specifically for interactive shells.

Re: BUG in arithcomp: bypass of the check condition and arbitrary read/write of shell variables

On Fri, Apr 10, 2020 at 09:44:31AM +, Raffaele Florio via Bug reports for the GNU Bourne Again SHell wrote: > Indeed the functions called by arithcomp cause the evaluation of the supplied > arithcomp function argument, potentially fed by user input. > Give in input "x=42,xyz=UID" to the belo

BUG in arithcomp: bypass of the check condition and arbitrary read/write of shell variables

Bash Version: 5.0 Patch Level: 11 Release Status: release Description: A bug in the function arithcomp (in test.c) allows an attacker to bypass every arithmetic check. Furthermore, this bug, allows an attacker to read/write arbitrary shell variables. The bug could be also triggered with the test

Re: ${!variable@operator} does not work for variables without values; inconsistencies between present and absent [@] for @A and @a

On 2/20/20 7:34 PM, Arfrever Frehtes Taifersar Arahesis wrote: >> Same answer as previously: maybe it should display the attributes >> even thought the variable is unset. > > Yes, I think that @A, [@]@A, @a and [@]@a should work for unset variables. OK, we'll try th

  1   2   3   4   5   6   >