Re: RFE: Please allow unicode ID chars in identifiers

On Sun, Jun 04, 2017 at 09:20:45AM +0700, Peter & Kelly Passchier wrote: > On 04/06/2560 04:48, L A Walsh wrote: > >> Greg Wooledge wrote: > >>> Here is a demonstration of the cost of what you are proposing. In my > >>> mail user agent, your variable shows

Re: Patch for unicode in varnames...

On Tue, Jun 06, 2017 at 07:01:23AM -0700, L A Walsh wrote: > George wrote: > >On Mon, 2017-06-05 at 16:16 -0700, L A Walsh wrote: > >>George wrote: > >>>On Mon, 2017-06-05 at 15:59 +0700, Peter & Kelly Passchier wrote: > On 05/06/2560 15:52, George wrote: > >there's not a reliable mechanism

Re: Patch for unicode in varnames...

On Tue, Jun 06, 2017 at 12:02:41PM -0700, L A Walsh wrote: > Bash *is* the linux > shell. It's being adopted elsewhere, but it seems to have first grown > in use in the linux community. Bash predates Linux. Bash was first released in 1989. Linux wasn't released until 1991. Bash is the GNU shel

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 12:38:19AM +0700, PePa wrote: > I would think this is a bug: > 4.3.48(1)-release> printf "q\n\n\n" >w > 4.3.48(1)-release> printf "$(cat w)" > q > 4.3.48(1)-release> > > Is there some workaround to somehow preserve the trailing newlines? It's not a bug. This is how comma

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 01:52:44AM +0700, Peter & Kelly Passchier wrote: > On 09/06/2560 00:42, Greg Wooledge wrote: > > foo=$(cat "$file"; printf x) foo=${foo%x} > > The workaround I came up with is: > mapfile <"$file"; IFS= foo=${MAPFILE[@]} >

Re: Trailing newlines disappear

ARGH! You dropped the list address! This was on bug-bash, right?? On Fri, Jun 09, 2017 at 03:14:10AM +0700, PePa wrote: > On 09/06/2560 02:14, Greg Wooledge wrote: > > Well, it leaves IFS changed, because you didn't revert or unset it, > > or run the entire thing in a fun

Re: Trailing newlines disappear

On Thu, Jun 08, 2017 at 10:44:29PM +0200, Geir Hauge wrote: > You can pick one of these instead: > > mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS > > or > > mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}" or lambda() { local MAPFILE IFS=; mapfile < "$file"; foo="${

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 08:06:28AM +0700, Peter & Kelly Passchier wrote: > On 09/06/2560 05:26, Eduardo Bustamante wrote: > > What's wrong with: > > > > IFS= read -rd '' foo < "$file" > > I think that's the winner! So long as you know the file doesn't contain any NUL bytes. The other variants w

Re: consistency probs w/ 'readonly -f' & 'export -f

that what you're looking for? Bear in mind, the environment variable name is dependent on which shellshock patch your version of bash uses. E.g. in Debian wheezy: greg@remote:~$ foo() { echo foo; }; export -f foo greg@remote:~$ env | awk '/_foo/{print; getline; print}' BASH_FUNC_foo()=(

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 09:22:58AM -0400, Chet Ramey wrote: > On 6/9/17 8:06 AM, Greg Wooledge wrote: > > imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n') > > imadev:~$ declare -p a > > declare -a a=([0]="foo" [1]="baz" [2]=

Re: Trailing newlines disappear

On Fri, Jun 09, 2017 at 08:58:05PM +0300, Pierre Gaston wrote: > Even if they don't realize it, few people would expect: > > var=$(wc -l file);echo "$var" > > to print 2 lines. imadev:~$ file=$'a\nb\nc\nd\ne'; touch "$file" imadev:~$ var=$(wc -l "$file"); echo "$var" 0 a b c d e > Trailing newl

Re: consistency probs var & function re-use

On Sun, Jun 11, 2017 at 03:51:26PM -0700, L A Walsh wrote: > I was pointing out that the reason 'declare' used a newline, was that he > had not quoted the input to 'x', which is expanded to a newline > before it is assigned to 'x'. You are completely wrong here. My variable 'x' had a newline in i

Re: RFE: Please allow unicode ID chars in identifiers

On Tue, Jun 13, 2017 at 04:44:08PM -0400, tetsu...@scope-eye.net wrote: > For that to work, basically the character encoding used to interpret > the script should be (potentially) distinct from the one used to > interact with the rest of the system. > > ...But that gets complicated: the shell woul

Re: RFE: Please allow unicode ID chars in identifiers

On Tue, Jun 13, 2017 at 08:06:50PM -0400, Chet Ramey wrote: > That works with Mac OS X, where the output of locale(1) is a series of > shell assignment statements with quoted values; your mileage may vary, of > course. POSIX d

Re: RFE: Please allow unicode ID chars in identifiers

On Tue, Jun 13, 2017 at 04:58:59PM -0700, L A Walsh wrote: > Forgive me if I'm misremembering, but hasn't Greg argued against > the ability to supply "libraries" of re-usable scripts due to > the ease with which names could conflict with each other and cause > scri

Re: RFE: Fix the name collision issues and typing issues with namerefs, improve various issues for function libraries

On Wed, Jun 14, 2017 at 12:04:35PM -0400, tetsu...@scope-eye.net wrote: > So first off, the circular reference problem with "declare -n" > apparently doesn't exist in Korn Shell: If you "typeset -n x=$1", and > $1 is "x", it's not a circular reference. Korn shell actually has two different *kinds*

Re: RFE: Fix the name collision issues and typing issues with namerefs, improve various issues for function libraries

On Mon, Jun 19, 2017 at 12:07:31AM -0400, George wrote: > ultimately identified in the nameref also comes from the caller) but the > inconsistency there, of "typeset -n" behaving differently depending on where > the name comes from, is very unappealing to me. I'd much rather see this > behavior a

Re: Regression -- can't read input w/stderr redirect

On Sun, Jun 18, 2017 at 07:17:46PM -0700, L A Walsh wrote: > Oh? I want to read in a value from the registry where something may > have zeros > after the data. Please tell me the mechanism to read this in w/no warnings > that won't silence more serious cases of zero's other than at the end of >

Re: Regression -- can't read input w/stderr redirect

On Tue, Jun 20, 2017 at 02:01:51AM -0700, L A Walsh wrote: > * BASH???s ???read??? built-in supports '\0' as delimiter Yes, but not with that syntax. It uses the -d '' option, which is undocumented, but supported according to . >

Re: Unexpected word splitting on $* when IFS is unset

On Wed, Jun 21, 2017 at 10:30:22PM -0400, Chet Ramey wrote: > However, not all shells were consistent in their interpretation of the > Posix rules. For instance, dash, which bills itself as being completely > Posix conformant, produces 1 for that case (and expands to "ab"). The > Bourne shell (SVR

Re: Unexpected word splitting on $* when IFS is unset

On Fri, Jun 23, 2017 at 10:27:44PM +0700, Robert Elz wrote: > $* is just $1 $2 ... (for as many params as set) as separate words. That's what I always thought too, but if commonly used shells like dash can't even agree on this, then I simply upgrade my response level from "bad practice" to "comple

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Sun, Apr 14, 2024 at 11:16:27AM +0200, Emanuel Attila Czirai wrote: > $ [ -n ">" -a -n "something" ] || echo hmm > bash: [: syntax error: `-n' unexpected > hmm Don't do this. You're in the land of unspecified behavior here. Use multiple test or [ commands instead, or use bash's [[ command.

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 07:04:23PM +0200, Emanuel Attila Czirai wrote: > In my superficial report, I definitely didn't think of that. I even forgot > to mention that it works when escaped like "\>" > > I've encountered it in the "adduser" FreeBSD sh script that runs as root, > while trying to set

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 08:13:23PM +0200, Emanuel Attila Czirai wrote: > On Mon, Apr 15, 2024 at 7:56 PM Greg Wooledge wrote: > > Sounds like you've found a nontrivial bug in FreeBSD (in the adduser > > script, not in sh). I hope this gets reported and fixed, and in any cas

Re: [sr #111051] New commands: `-h`, `--help`

On Thu, Apr 18, 2024 at 03:03:32AM -0400, anonymous wrote: > they gave me reply: > > 'There isn't command `-h` on my Limux' > > Therefore, after calling -h/--help, I suggest displaying a message like: Adding a /usr/bin/-h command or whatever sounds like overkill to me. I wouldn't want that t

Re: [sr #111051] New commands: `-h`, `--help`

On Thu, Apr 18, 2024 at 03:20:21PM +0700, Robert Elz wrote: > ps: bash could probably lose the "be a login shell" '-' from argv[0][0] > for error messages. It isn't helpful. It's a tiny bit helpful for someone who knows what it means, and harmless for people who don't know. I'd prefer it to be

Re: Erasing sensitive data from memory?

On Sun, Apr 21, 2024 at 02:16:57PM -0400, Zachary Santer wrote: > $ IFS='' read -e -r -s -p 'password: ' password > password: seems to be relevant here. I won't say that you have malicious intent here, but a script that behaves in this way is just a step o

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

On Mon, Apr 22, 2024 at 08:13:16AM +0200, felix wrote: > Then after some tests: > > if ls /wrong/path | wc | cat - /wrong/path | sed 'w/wrong/path' >/dev/null > ; then > echo Don't print this' > fi ; echo ${?@Q} ${PIPESTATUS[@]@A} $(( $? ${PIPESTATUS[@]/#/+} )) > > ls: cannot access

Re: [PATCH 0/4] Add import builtin

On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote: > Much like the periodic requests for XDG-organized startup files, a > BASH_SOURCE_PATH might be convenient but is not groundbreaking and > probably doesn't merit significant changes to the shell. I'm not > even convinced it merit

Re: [sr #111058] Problem transmitting script arguments

On Wed, May 08, 2024 at 02:07:55PM -0400, 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 > > Savannah issue filer. > > OK. Now does

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk What is "wc -l" supposed to read from? It counts lines of standard input, until EOF is reached. But its standard input is a terminal. And you're r

Re: bug in bash

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote: > > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > >> I found a bug when i tried with syntax <(cmd). this is an example > >> cat <(wc -l) < bk > Since the redirection fails and the cat command is never started, bash >

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 14, 2024 at 03:51:10PM -0400, 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 varia

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024 at 10:51:01AM +0700, Robert Elz wrote: > Personally, I don't think there is anything common here at all, most > scripts don't fetch bits from other places, everything simply goes in > the script, and the need for the '.' command at run time is avoided. > > In general, I suspec

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote: > On 5/15/24 11:31 AM, Koichi Murase wrote: > > Maybe it was not clear to use `source name' and `source -i name' to > > describe the idea. I meant I assumed the search domain being > > > > * BASH_SOURCE_PATH + PATH + PWD without the optio

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 02:23:10AM +, Matheus Afonso Martins Moreira wrote: > It's also important to consider the opposite situation: > distributions and/or users setting BASH_SOURCE_PATH globally > which then results in existing scripts _not_ getting the historical > behavior which matches wha

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 01:42:43PM +0700, Robert Elz wrote: > [GLOBSORT] > Possibly useful I guess - though I'm not really sure about a possible > need to stat() every file from a glob result because that got set to > one of the options that needs it. "nosort" seems likely to be the most > useful

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 03:32:23PM +, Matheus Afonso Martins Moreira wrote: > > You don't have to export variables. I would recommend not exporting > > such a variable to begin with unless you're sure of its effects. > > It could be made safe so that it's possible to export it. > Then it can a

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Sat, May 18, 2024 at 08:39:57AM -0300, Matheus Afonso Martins Moreira wrote: > > Setting the variable at all is opting in to new behavior, and you do > > that at your own risk, after reading the documentation and deciding > > that this is what you want. > > As the user, it should be my prerogat

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote: > On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira > wrote: > > >> Why not add a -p option to '.' to specify the path to search. > > >> That is > > >>. -p "${BASH_SEARCH_PATH-${PATH}}" file > > >> would wor

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira wrote: > > the schizophrenic nature of the feature > > First the feature was "irritating" ... Now it's "schizophrenic" ? > I must be mentally ill for trying to contribute this? > > Yeah, I'm done. I don't think "schizophren

Re: sh vs. bash -xc 'a=b c=$a'

On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: > It seems these should both make one line "+ a=b c=b" output, > > for s in sh bash > do $s -xc 'a=b c=$a' > done > > I mean they give the same results, but bash splits it into > two lines, so the user reading the bash -x output cannot

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote: > Also note that to actually put floating support in the shell, more is > needed than just arithmetic, you also need floating comparisons in test > (or in bash, in [[ ) and a whole bunch more odds and ends that aren't > obvious until you n

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wrote: > the most obvious use of floating variables would be to compare > balances and to branch based on if a balance is lower than a certain > value > I use: > t=$(python3 -c "import math;print($balance > 0)") > and the > if [ "$t" == "False

Re: Echoing commands

On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote: > "set -x" makes the ensuing commands be printed, but prefixed > with "+ ", which makes the result look ugly, not to mention that > the following "set +x" is echoed too (there are hacks to suppress > the "set +x" output, but they are

Re: Echoing commands

On Thu, Jun 13, 2024 at 10:01:16AM +0200, Angelo Borsotti wrote: > @echo-on > cat f1.txt f1.txt > f1.tmp > @echo-off > > I.e. the command is not entirely displayed. Yeah. This is what I mentioned originally: set -x does not show redirections. Ever. There is no workaround for this currently. A

Re: Echoing commands

On Thu, Jun 13, 2024 at 11:51:13AM -0400, Dale R. Worley wrote: > For instance, how should this be logged? > > $ { echo foo ; echo bar ; } >/dev/null > + echo foo > + echo bar I'm 99% sure I know what answer the OP of this thread will give: "It should write '{ echo foo ; echo bar ; }

Re: it, soRE: set -a leads to truncated output from ps

On Thu, Jun 13, 2024 at 06:28:23PM +, Alain BROSSARD via Bug reports for the GNU Bourne Again SHell wrote: >My conclusion is that the variable COLUMNS gets “reset” when there is a > pipe in a command and further gets EXPORTED if “set -a” was set before hand : > > host:/$ COLUMNS=80 > hos

Re: set -a leads to truncated output from ps

On Thu, Jun 13, 2024 at 06:12:21PM +0200, Andreas Schwab wrote: > Why do you think this is a bug in bash? You are telling the shell to > export any modified variable, and you get what you asked for. I started writing something like this as well but deleted it. I think there's still a bit of subt

Re: Poor messages when the '#!' file isn't found

On Fri, Jun 14, 2024 at 02:13:37AM +0800, Dan Jacobson wrote: > $ echo \#!/usr/bin/python > k > $ chmod +x k > $ ./k > bash: ./k: cannot execute: required file not found > > Bash should really mention what file it is talking about. Bash doesn't KNOW what file is missing. All it knows is that the

Re: set -a leads to truncated output from ps

on in Debian 12 seems fine to me: hobbit:~$ COLUMNS=60 ps ww -fp 192331 UID PIDPPID C STIME TTY STAT TIME CMD greg 192331 192024 0 07:11 tty1 Sl 0:00 /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=192013 --enable-crash-reporter=CB81BA40-8F5C-190E

Re: set -a leads to truncated output from ps

On Fri, Jun 14, 2024 at 11:36:19AM +, Alain BROSSARD wrote: > ps axww isn’t impacted, but the scripts use ‘ps ax’. Oh. Well then, that's the most obvious thing to fix.

Re: set -a leads to truncated output from ps

On Sat, Jun 15, 2024 at 07:48:42AM +0300, Oğuz wrote: > Right now, if you're dealing with such a program while `set -a' is in > effect, in order to suppress COLUMNS you need to unexport it before every > command: Or just turn off checkwinsize.

Re: Question that baffles AI (all of them)

On Sat, Jun 15, 2024 at 05:30:17PM -0400, Saint Michael wrote: > in this code: > data="'1,2,3,4','5,6,7,8'" > how can I get my (a) and (b) arguments right? > The length of both strings is unpredictable. > a="1,2,3,4" and b="5,6,7,8"" This is a parsing problem. Bash is not a particularly good cho

Re: bash crashes when splitcurl script try download non existent file

On Fri, Jun 21, 2024 at 22:26:07 +0500, Mikhail Gavrilov wrote: > On Fri, Jun 21, 2024 at 10:06 PM Chet Ramey wrote: > > Bash allows recursive trap handlers. > > Ok. But it's very suspicious for me because the script ended without > any issues on macOS. > > mikhail@MBP-Mikhail ~> ./splitcurl.sh

Re: readarray leaves a NULL char embedded in each element

On Mon, Jun 24, 2024 at 10:50:15 -0600, Rob Gardner wrote: > Description: > When using space or newline as a delimiter with readarray -d, > > elements in the array have the delimiter replaced with NULL, > > which is left embedded in each element of the array. This isn't p

Re: readarray leaves a NULL char embedded in each element

On Mon, Jun 24, 2024 at 20:01:45 +0200, Davide Brini wrote: > $ ./printarg "${X[0]}A" > 65 32 65 0 83 > > That is, "A", a space, and "A" again (which is the result of the quoted > expansion), 0 for the string terminator, and a random 83 which is > whatever follows in memory (strangely, it seems to

Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices

On Wed, Jun 26, 2024 at 14:09:13 -0400, Zachary Santer wrote: > > > Imagine this functionality: > > > $ array=( zero one two three four five six ) > > > $ printf '%s\n' "${array[@]( 1 5 )}" > > > one > > > five > I did want to see if others would find this valuable, and no one spoke > up, so it's

Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices

On Fri, Jun 28, 2024 at 08:50:50 -0400, Zachary Santer wrote: > Is "${array[@]( "${indeces[@]}" )}" ugly? Does that matter? It seems > like a good way to write what's happening. I still have to look up > some of the less-commonly-used parameter expansions every time I use > them. I think people wou

Re: printf fails in version 5.2.026-3

On Wed, Jul 03, 2024 at 22:24:43 +0200, szige...@delg0.elte.hu wrote: > Description: > printf works in version 5.2.026-2, fails in version 5.2.026-3 What exactly are these version numbers? Are they packages from some Linux distrbution? > Repeat-By: > contents of tmp.sh begins ---

Re: waiting for process substitutions

On Fri, Jul 05, 2024 at 15:16:31 -0400, Chet Ramey wrote: > They're similar, but they're not jobs. They run in the background, but you > can't use the same set of job control primitives to manipulate them. > Their scope is expected to be the lifetime of the command they're a part > of, not run in t

Re: proposed BASH_SOURCE_PATH

On Sun, Jul 07, 2024 at 21:23:15 +0200, alex xmb sw ratchev wrote: > hi .. > i dont get the BASH_SOURCE[n] one > the point of prefix $PWD/ infront of relative paths is a static part of > fitting into the first lines of the script , assigning vars > .. if u cd first then want the old relative path .

Re: waiting for process substitutions

On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote: > On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote: > > > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote: > > > > > hi , one question about .. > > > if a cmd contains more substitions like >( or <( , how to get all $! > > > maybe make ${

Re: Env var feature request

On Tue, Jul 09, 2024 at 20:14:27 +, Erik Keever wrote: > A --debug-envvars flag which will, when passed to bash, catch every time an > environment variable is set and print the file/line that is setting it. To > restrict it, "--debug-envvars FOO,BAR" to catch only instances of FOO or BAR > b

Re: Local variable can not unset within shell functions

On Thu, Jul 11, 2024 at 15:39:41 -0400, Lawrence Velázquez wrote: > I won't speculate about the issue, but your subject goes too far. > The variable really is unset here: > > % cat /tmp/x.bash > x() { > local x=y > declare -p x > echo "x is ${x

Re: pwd and prompt don't update after deleting current working directory

On Fri, Jul 12, 2024 at 10:26:54 +0700, Robert Elz wrote: > Is it supposed to continually run "stat($PWD, ...)" forever (after > all the directory might be removed from elsewhere while you're in > the middle of typing a command - what do you expect to happen then?) It's even worse: let's say a new

Re: waiting for process substitutions

and it's how most people *think* wait -n currently works. The common use case for "wait -n" is a loop that tries to process N jobs at a time. Such as this one: greg@remote:~$ cat ~greybot/factoids/wait-n; echo Run up to 5 processes in parallel (bash 4.3): i=0 j=5; for elem in &

Re: [Bug] Array declaration only includes first element

On Thu, Jul 18, 2024 at 00:00:17 +, Charles Dong via Bug reports for the GNU Bourne Again SHell wrote: > - Declare an array: `a=(aa bb cc dd)` > - Print this array: `echo $a` or `printf $a` $a is equivalent to ${a[0]}. That's not how you print an entire array. The easiest way to print an ar

Re: if source command.sh & set -e issue

On Wed, Jul 24, 2024 at 16:23:35 +0300, Mor Shalev via Bug reports for the GNU Bourne Again SHell wrote: > script.sh contain: > if source command.sh ; then > echo pass > else > echo fail > fi > command.sh contain 'set -e' at start. so command.sh should exit once detect > fail. > > once callin

Re: if source command.sh & set -e issue

On Wed, Jul 24, 2024 at 20:53:33 +0300, Mor Shalev via Bug reports for the GNU Bourne Again SHell wrote: > *if source command.sh ; then echo passfi* > Or, similarly: > > *source command.sh && echo pass* Remember how -e is defined: -e Exit immediately if a pipeline (which m

Re: Backticked, nested command will steal piped stdin

On Tue, Jul 30, 2024 at 14:06:21 -0400, Dale R. Worley wrote: > In your case, you probably want > > > $ seq 3 | head -n $(

Re: [bug #66068] built-in printf function not working with float

On Tue, Aug 06, 2024 at 05:58:56 -0400, anonymous wrote: > jesusm@liet:[~]$ bash --version > GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu) > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This

Re: whats wrong , exit code 11 on android termux

On Tue, Aug 06, 2024 at 20:59:08 +0200, alex xmb sw ratchev wrote: > maybe its this i completly dunno > > i guess i must start use devel branch ? > > On Tue, Aug 6, 2024, 20:45 Grisha Levit wrote: > > > On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev wrote: > > > >> ~ $ alias tm='timemark+=( $E

Re: 'wait -n' with and without id arguments

On Fri, Aug 09, 2024 at 13:59:58 -0400, Zachary Santer wrote: > I don't necessarily understand why someone would call 'wait -n' from > the interactive shell, so I don't really know what the desired > behavior would be when they do so. Would be nice if other people want > to chime in on that point.

Re: 'wait -n' with and without id arguments

On Fri, Aug 09, 2024 at 15:20:52 -0400, Zachary Santer wrote: > On Fri, Aug 9, 2024 at 2:52 PM Greg Wooledge wrote: > > > > The problem is that our entire understanding of what "wait -n" DOES has > > been annihilated. We thought it would "trigger" exactl

Re: printf inconsistent results for %.0f

On Mon, Aug 12, 2024 at 16:30:26 +0200, Laur Aliste wrote: > Configuration Information: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-pr

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 02:45:25 +0200, Steffen Nurpmeso wrote: > I include bug-bash even though i think bash is correct, but there > lots of people of expertise are listening, so, thus. > Sorry for cross-posting, nonetheless. > Given this snippet (twox() without argument it is) > > one() { echo

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 11:04:08 +0200, Marc Chantreux wrote: > > We know what "$@" is supposed to do. And something like "x${@}y" is > > well-defined also -- you simply prefix "x" to the first word, and append > > "y" to the final word. > > > But I don't know how "$@$@" is supposed to be interpr

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 17:58:15 +0300, Oğuz wrote: > On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > > However, as ksh93 makes "" from this > > expansion, and so probably ksh88 might have done as well > > No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0. HP-UX 10.20 a

Re: $@ in function gives error

On Fri, Aug 16, 2024 at 18:59:15 +0200, freek--- via Bug reports for the GNU Bourne Again SHell wrote: > #!/bin/bash > init() { > [ -n "$@" ] && echo $@ > } > init $@ You have multiple errors in this script. The first error is that you used $@ without quotes, twice. If you want to preserve the

Re: $@ in function gives error

On Sat, Aug 17, 2024 at 12:41:45 +0200, Freek de Kruijf wrote: > Apparently I have a problem with the concept of $@, I see it as list of zero > or more non-whitespaced elements, and quotes around it makes it into a single > element. Like a parameter p with a content of zero or more non-whitespace

Re: Bash History Behavior Suggestion

On Mon, Aug 19, 2024 at 15:52:22 -0400, supp...@eggplantsd.com wrote: > I would suggest: > 2. Restrict up-arrow completion to the history of present session. This is going to be an *extremely* unpopular suggestion. Though, I must wonder: do you literally mean *only* the up-arrow (or Ctrl-P or ESC

Re: Question on $@ vs $@$@

On Fri, Aug 23, 2024 at 01:28:49 +0200, Steffen Nurpmeso wrote: > a() { echo $#,1=$1,2=$2,"$*",$*,; } > set -- a b c > echo 2 > IFS=:; echo "$*"$*; a $* "$*"; Your printing function "a" is highly questionable. It's got unquoted word expansions that'll do who knows what, and it's also usin

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

On Sat, Aug 24, 2024 at 02:15:48 +0200, Steffen Nurpmeso wrote: > a() { > echo $#,1=$1,2=$2,"$*",$*, > } You didn't read a word I said, did you *Sigh.*

Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

On Sat, Sep 14, 2024 at 19:46:21 +0800, ~ via Bug reports for the GNU Bourne Again SHell wrote: > Dear bug-bash team: >   I hope this email finds you well. During my recent security > assessment of bash, I identified a potential security vulnerability that I > believe may impact the security of

Re: Call dynamic builtins with 'builtin' command

On Sat, Oct 12, 2024 at 16:55:31 -0400, Chet Ramey wrote: > On 10/9/24 7:15 AM, Vadim Nevorotin wrote: > > 2. Can you explain how to load and use e.g. stat builtin without > > overwriting the current behavior of stat in the whole existing script? > > Is this anything more complicated than doing >

Re: aliases sometimes not expanded even with expand_aliases set

On Sun, Oct 13, 2024 at 00:01:10 +1030, i...@beware.dropbear.id.au wrote: > In the following script, the first alias fails with "comand not found" > but the second works. > > #!/bin/bash > > shopt -s expand_aliases > > if :; then > alias foo='ec

Re: Fwd: New feature

On Sat, Oct 12, 2024 at 09:50:03 -0400, Saint Michael wrote: > The command printf needs a new flag, -e, that would mimic that way the > same flag works with echo. > After using printf, right now I need to lunch a second command if I > need to expand the \n into real new lines. > > PROCEDURE_INFO=

Re: Call dynamic builtins with 'builtin' command

On Wed, Oct 09, 2024 at 15:15:52 +0400, Vadim Nevorotin wrote: > According to 'help enable' this should work, but it also do not: > > $ enable stat > $ enable -n stat > $ builtin stat > bash: builtin: stat: not a shell builtin > > 'enable -n' should just disable stat, according to 'help enable',

Re: Fwd: read command sometimes misses newline on timeout

> -- Forwarded message -- > From: *Thomas Oettli* >1. the script calls "read" on pipe >2. "read" hits timeout just after it has read "\n" from the pipe >3. "read" returns the full line, but exits with rc > 128 >4. the script assumes a partial line, appends received

IFS whitespace definition

This issue came up on the Libera #bash IRC channel today: Between bash 4.4 and 5.0, the definition of "IFS whitespace" has apparently been expanded: hobbit:~$ bash-4.4 hobbit:~$ ( s=$'a\r\r\rb'; IFS=$'\r' read -ra a <<< "$s"; declare -p a ) declare -a a=([0]="a" [1]="" [2]="" [3]="b") hobbit:~$ e

Re: bash -xv issue with stderr

On Sun, Nov 03, 2024 at 11:28:24 +0100, Christoph Zimmermann wrote: > Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which unfortunately does require a CB change). > > If this is intended behaviour, it should be clearly documented on the > corresponding man pa

Re: [EXTERNAL] - Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

On Fri, Nov 08, 2024 at 15:33:29 +, David Linden wrote: > FYI, since I'm reporting behavior of 4.2 and this appears fixed in 4.4. > > In 4.2, it seems that providing the =() as part of the declaration throws > away the -g-ness of the declaration-within-a-function. I need to touch it > after

Re: Suggested BASH Improvement

On Wed, Sep 18, 2024 at 10:51:51 -0400, Chet Ramey wrote: > On 9/17/24 7:50 PM, BRUCE FOWLER via Bug reports for the GNU Bourne Again > SHell wrote: > > An interesting problem I ran into recently: > > I have a shell script that I run about once a month that > > "screen-scrapes" from the output of a

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

On Wed, Sep 18, 2024 at 08:05:10 +0300, Oğuz wrote: > On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso wrote: > > > > It boils down to this: > > f(){ echo $#;}; set "" "" ""; IFS=x; f $* > > bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh > prints 3 but mksh and oksh print

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 02:56:05 -0400, Lawrence Velázquez wrote: > This question is more appropriate for help-bash than bug-bash. > > On Tue, Sep 17, 2024, at 2:21 AM, William Park wrote: > > For splitting, I'm aware of > > old="a,b,c" > > IFS=, read -a arr <<< "$old"

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 16:07:58 +0200, alex xmb sw ratchev wrote: > savedifs=${IFS@A} savedifs=${savedifs:- unset -v IFS } > str=1,2,3 IFS=, arr=( $str ) joined=${arr[*]} > eval "$savedifs" Using unquoted $str in an array expansion to do the splitting has a couple drawbacks: 1) Globbing (filenam

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 17:00:16 +0200, alex xmb sw ratchev wrote: > plz what does 'local -' do , its newer to me > i forgot all about it already local [option] [name[=value] ... | - ] For each argument, a local variable named name is created, and assigned valu

Re: Bash 5.2: broken built-in printf for float numbers

On Thu, Nov 07, 2024 at 10:16:46 +0100, Thomas Dreibholz wrote: > Hi, > > Bash 5.2 has a broken built-in printf for float numbers. > > Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale > LC_ALL=C.UTF-8) > > Testing the Bash shell in different versions of recent Debian and

Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

On Thu, Nov 07, 2024 at 02:38:05 +, David Linden wrote: > Description: > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo > ${#foo[@]} > How am I supposed to determine that a declared associative array is > empty? The easiest way would be to ensure that the array

<    14   15   16   17   18   19   20   >