Re: ;exit in bash history causes bash to exit

Ethan Gascoigne writes: > Narrowed it down to the line `eval "$(fasd --init auto)"` in my > .bashrc. Must be some kindof bug with fasd > (https://github.com/whjvenyl/fasd). Any idea how fasd could cause > `;exit` to be interpreted as a valid command? Running `alias exit` > shows that it's not alia

Re: history writes to process substitution but errors reading it

Andreas Schwab writes: > On Feb 14 2025, Dale R. Worley wrote: > >> And really, that means that the effect of -r is kind of complicated and >> unintuitive. > > Not really. The command uses either the supplied filename or $HISTFILE > to name the file to operate on. Ot

Re: history writes to process substitution but errors reading it

Chet Ramey writes: > It fails because the history library requires the file to be a regular > file. It tries to read and write atomically, so the read history function > gets the size of the history file, allocates one big buffer to hold it, > and reads it in one go. Though in regard to the comma

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Andrés Rodríguez Reina writes: ... > Due to a mistake in coding a script, a folder named '~' was > generated. An unexperienced bash user issued the command "rm -rf ~" by > mistake, intending to delete the '~' folder, but this resulted in > deleting 150GB+ of data at their home directory. It mig

Re: bind allows "impossible" key bindings without warning

Andreas Schwab writes: >> It does seem like "bind" could be improved by providing an option that >> shows all of the keysequences and what they are bound to. > > bind -p | sort There's "bind -P", which lists "function names" and bindings, and then there's "bind -S", which lists "key sequences bou

Re: bind allows "impossible" key bindings without warning

It does seem like "bind" could be improved by providing an option that shows all of the keysequences and what they are bound to. Currently, there seem to be several options for listing different types of bindings, but they all seem to be conceptually oriented toward "I am thinking of an action, wh

Re: Consolidate recommended options?

Daniel Colascione writes: > I wonder whether it would be possible to add a simple catch-all command > that would encompass a set of options that can't be defaults but that > make writing shell scripts easier, e.g. set -euo pipefail, nullglob, > inherit_errexit, extglob, assoc_expand_once, and vari

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Greg Wooledge writes: >> You need to escape one of the types of quotes. Double quotes is >> generally simpler: >> >> $ x="foo \"foo\" and 'bar' content" >> $ echo "$x" >> foo "foo" and 'bar' content > > Only in this restricted case. Using double quotes as the outer layer > means you have to back

Re: history -s from inside function replaces last command rather than adding to it

Chet Ramey writes: > On 12/17/24 5:19 PM, Dale R. Worley wrote: > but it's tough to use programatically: How would >> you code a function for use in scripts that adds an entry "foo bar baz" >> to the history list without removing anything already on the history

Re: history -s from inside function replaces last command rather than adding to it

Chet Ramey writes: >> What is the point of "history -s args", then? What is it useful for? > > To add arbitrary data to the history list, for whatever reason a user > likes. I think the documentation is fairly clear on that. To be more specific, it adds arbitrary data to the history list, but al

Re: history -s from inside function replaces last command rather than adding to it

Chet Ramey writes: > Yes: > > -s Store the args in the history list as a single entry. > The last command in the history list is removed before > adding the args. > > That last command is usually `history -s args'. What is the point of "history

Re: PIPESTATUS differs from $? for compound command

Chet Ramey writes: > On 12/11/24 9:54 PM, Dale R. Worley wrote: >> This needs to be corrected to note that compound commands that are not >> one component of a multi-command pipeline do not cound as pipelines for >> setting PIPESTATUS. Exactly which compounds commands do

Re: Very Unexpected response from command 'set'

It would have helped greatly if you'd captured set's output as a text file rather than sending us a screenshot of the end of the text. Just do $ set >set.out Dale

Re: PIPESTATUS differs from $? for compound command

My opinions on this subject: It's probably not worth changing the behavior, particularly since there is likely to be some small amount of code out there that depends on it. The behavior in regard to ! is correct (as has been noted) because PIPESTATUS records the values of the commands in the pipe

Re: PIPESTATUS differs from $? for compound command

My opinions on this subject: It's probably not worth changing the behavior, particularly since there is likely to be some small amount of code out there that depends on it. The behavior in regard to ! is correct (as has been noted) because PIPESTATUS records the statuses of the commands in the pi

Re: PIPESTATUS differs from $? for compound command

"Dale R. Worley" writes: >> $ if false; then :; fi | true; echo ${PIPESTATUS[*]} >> 0 0 Trying to dissect this: There are *three* pipelines that are executed: 1) 'if false; then :; fi | true' 2) 'false' (which is a pipeline, which is a list, whic

Re: PIPESTATUS differs from $? for compound command

Andreas Schwab writes: >> But the PIPESTATUS refers to the 'false' pipeline: >> $ if false; then :; fi; echo ${PIPESTATUS[*]} >> 1 > > $ if false; then :; fi | true; echo ${PIPESTATUS[*]} > 0 0 > > Why is that not `1 0'? After all, the last executed commands as part of > the pipeline (b

Re: eval '<$(;)' causes Segmentation Fault

writes: > Repeat-By: > 1. Create a script, i.e. `poc.sh` with the problematic string > 2. Execute `bash poc.sh` Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I don't get the seg fault when I enter that string from the keyboard, only when it's read from a scrip

Re: Bogus (intptr_t) casts

Martin D Kealey writes: > It follows that the following assertions are allowed to fail: > > intptr_t i = 0; > assert((void*)i == (void*)0); > void *p = 0; > assert((intptr_t)p == 0); (After removing the bogus "*" that got inserted.) Yeah, it looks like that's correct; there doesn't seem

Re: Backticked, nested command will steal piped stdin

Justus writes: > I found a bug in my beloved bash and hope that you can fix it! > $ seq 3 | head -n $(calc -dp "1+1") This actually isn't a bug; a command substitution inherits the fd's except for 1 (stdout) (which is captured by bash to create the command substitution). Command su

Re: waiting for process substitutions

Greg Wooledge writes: > Some scripts use something like this: > ... > exec > >(command ...) ... I've used that construction quite a few times myself. I'm not requesting that the resulting process be waitable, but certainly whatever the maintainers design should take into account that this is

Re: Comments on bash 5.2's undocumented <((

Emanuele Torre writes: > Yes, clearly that is influencing this new behaviour, but this is new: > <((

Re: Comments on bash 5.2's undocumented <((

Emanuele Torre writes: > Bash 5.2 apparently added <(< file) that expand to the path to a fifo > (openable only for read on BSD) to which the contents of file are > written to, without documenting it. I suspect that this is a consequence of The com‐ mand substitution $(cat

Re: waiting for process substitutions

Reading this discussion, I notice a subtlety. If you execute: $ command-A >( command-1) <( command-2 ) $ command-B when command-B executes, command-2 must have terminated already because command-A wouldn't have seen the EOF from command-2 until command-2 terminated. (OK, I am assuming here that

Re: [@]@A weird behaviour when IFS does not contain space

Emanuele Torre writes: > [...] > Today, I have noticed that if IFS is set to a value that does not > include space, [@]@A will expand to a single value > [...] > As an aside, [*]@A always expands to the declare command joined by > space, even if the first character of IFS is not space; I think tha

Re: Echoing commands

Angelo Borsotti writes: > the solution to show commands with "set -x" has, however, a flow: it > does not show properly commands that contain redirections. E.g., ... > cat f1.txt f1.txt > f1.tmp But showing redirections properly is difficult, not just in the implementation, but in what it *means*

Re: [sr #111058] Problem transmitting script arguments

"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 that mean that there is no way for me to

Re: [sr #111058] Problem transmitting script arguments

anonymous writes: > URL: > > > Summary: Problem transmitting script arguments > Date: Sat 04 May 2024 10:08:41 AM UTC By: Anonymous > I have the following problem with transmitting arguments to a bash script > onward to an inside progr

Re: [PATCH 0/4] Add import builtin

It seems like you could get much the same effect with this device: -- t1 contains: # Where I am doing this testing. BASH_IMPORT_PATH=$HOME/temp/import/t2 echo "Note PATH does not contain '.'" echo "PATH=$PATH" echo "BASH_IMPORT_

Re: Scope change in loops with "read" built-in

"Linde, Evan" writes: > In a loop constructed like `... | while read ...`, changes to > variables declared outside the loop only have a loop local > scope, unlike other "while" or "for" loops. Yeah, that's a gotcha. But it's a general feature of *pipelines*, documented in Each command i

Re: feat: exit 1 "file not found"

teknopaul writes: > Hi not sure if this is the correct forum... I believe this is the correct forum. > exit builtin accepts one and only one arg currently. > > Would it be backwards compatible and generally useful to support > echoing a reason for exiting? > > test -f file || exit 2 "file not fo

Re: human-friendly ulimit values?

Christian Convey writes: > When setting memory-size limits via "ulimits", users have to manually > convert from their intuitive units. > > E.g., for limiting virtual memory to 8 gigabytes, the invocation is "ulimit > -v 8388608", rather than something like "ulimit -v 8gb". > > If I were to submit

Re: Slow history load with some values of HISTSIZE

Casey Johnson writes: > In a clean shell, execute: > HISTFILE=alt-history.txt > HISTSIZE=15 > history -r > and then observe how long the last command runs before returning. Though I expect that when you exit bash, the history file gets trimmed to 15

Re: wait -n misses signaled subprocess

Chet Ramey writes: >> echo "wait -n $pid return code $? @${SECONDS} (BUG)" > > The job isn't in the jobs table because you've already been notified about > it and it's not `new', you get the unknown job error status. The man page gives a lot of details and I'm trying to digest them into a structu

Re: wait -n misses signaled subprocess

Steven Pelley writes: > wait -n > fails to return for processes that terminate due to a signal prior to > calling wait -n. Instead, it returns 127 with an error that the > process id cannot be found. Calling wait (without -n) then > returns its exit code (e.g., 143). My understanding is that t

Re: completion very slow with gigantic list

Eric Wong writes: > Hi, I noticed bash struggles with gigantic completion lists > (100k items of ~70 chars each) A priori, it isn't surprising. But the question becomes "What algorithmic improvement to bash would make this work faster?" and then "Who will write this code?" Dale

Re: Unexpected Quick Substitution in string literals

Chet Ramey writes: >> While declaring a string literal across multiple lines, a line starting >> with the ^ character is resulting in some sort of quick substitution >> processing. > > This is a standard form of history expansion, described in the man page. I just checked. Certainly, the use of

Re: Regex: A case where the longest match isn't being found

"Dan Bornstein" writes: > I found a case where the regex evaluator doesn't seem to be finding > the longest possible match for a given expression. The expression > works as expected on an older version of Bash (3.2.57(1)-release > (arm64-apple-darwin22)). > > Here's the regex: ^(\$\'([^\']|\\\')*\

Handling of SIGHUP

The basic explanation of how Bash handles SIGUP is (in 5.1): The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the

Re: variable set in exec'ing shell cannot be unset by child shell

Ti Strga writes: > The summary is that if a parameter is set specifically for a '.'/'source' > command, and the source'd file calls 'exec' to run another script, then > that exec'd script cannot unset the parameter; if we want that parameter > to not be present in the exec'd script, then the sourc

Re: using exec to close a fd in a var crashes bash

Is there any way to write a redirection "Redirect the fd whose number is in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and assemble a command string however you want. But is there a direct way to write it? The "{var}>..." mechanism *assigns* to $var, rather than taking its existin

Re: ! history expansion occurs within arithmetic substitutions

Andreas Schwab writes: >> More troublesome, I think, are several variable substitutions which >> include "!" followed by a name. But I doubt they're used much in >> interactive mode. > > The history expansion is smart enough to not interfere with ${!var}. Yes... Also, the same magic seems to ap

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > When messing around in interactive mode to test things I may want to do in > a script, it's nice if it actually behaves the same. There are probably > some other set and possibly shopt things I should have somewhere if that's > what I want. I checked, and it doesn't seem

Re: !; is interpreted as an history expansion that can never match anything

Emanuele Torre writes: > ! followed by a ; or another terminator is interpreted as an history > expansion with no pattern that can never match anything. > > $ !; echo hi > bash: !: event not found > $ !&& echo hi > bash: !: event not found IMHO it is more to the point that in the manual

Re: ! history expansion occurs within arithmetic substitutions

Zachary Santer writes: > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be what the user wants. And now I know how to make it not > happen. > > Repeat-By: > $ set +o histexpand Well, yes, if you turn off history expansion, then it won'

Re: comments inside command subst are handled inconsistently

Denys Vlasenko writes: > Try these two commands: > > $ echo "Date: `date #comment`" > Date: Thu Jul 27 10:28:13 CEST 2023 > > $ echo "Date: $(date #comment)" >> )" > Date: Thu Jul 27 10:27:58 CEST 2023 > > As you see, #comment is handled differently in `` and $(). > I think the handling in `` make

Re: git amend commit with backticks on cli causes tty to crash

Wiley Young writes: > I'm seeing this behavior on Fedora 38. Possibly it's just some user error > again, since i'm figuring out how to use vim and git at a slightly above > novice level. :-) Well, I think I can get an idea of what you're doing. I'm not sure, you really want to create a "minima

Re: nofork command substitution

Chet Ramey writes: > Bash allows the close brace to be joined to the remaining > characters in the word without being followed by a shell metacharacter > as a reserved word would usually require. I had to read this a couple of times to figure out what it means. In particular "the word" isn't wel

Re: nofork command substitution

Ángel writes: > I suggest: > >> There is an alternate form of command substitution: >> >> ${ COMMAND; } > > and clarify later the other variants in addition to a space: > >> The character following the open brace must be a space, tab, >> newline, '(', or '|', and the close brace must

Re: How difficult would it be to add a timeout to "wait"?

Chet Ramey writes: > On 4/20/23 1:53 PM, Dale R. Worley wrote: >> How difficult would it be to add an optional timeout argument to the >> "wait" builtin? > > Try a variant of this. > ... My interest here isn't "Can I accomplish this task with B

How difficult would it be to add a timeout to "wait"?

How difficult would it be to add an optional timeout argument to the "wait" builtin? I occasionally run into situations where this functionality is desirable, more often than I expect, really. And though the last thing Bash needs is an additional feature, naively it seems like it wouldn't be too

Re: Document that here strings don't support brace expansion.

Chet Ramey writes: > If they're linked, why wouldn't saying filename generation isn't performed > be enough to imply that brace expansion isn't performed either? Hmm, yes, good point. Dale

Re: Document that here strings don't support brace expansion.

Alex Bochannek writes: > "The WORD undergoes tilde expansion, parameter and variable expansion, > command substitution, arithmetic expansion, and quote removal. Filename > expansion and word splitting are not performed." > > It is missing brace expansion, which is not supported: Interesting ...

Re: The memory occupied by bash has been increasing due to the fork bomb

zju <21625...@zju.edu.cn> writes: >> Interactive shells always ignore SIGTERM. > > I confirmed that the fork bomb through bash would cause the system > oom! This indicates that anybody can use this flaw to crash the > system.It is quite dangerous. > > If you think the behavior of ignoring the SIGTE

Re: Having an alias and a function with the same name leads to some sort of recursion

Chet Ramey writes: > On 2/14/23 2:58 PM, Dale R. Worley wrote: >>>> Looking at the manual page, it says >>>> >>>> ALIASES >>>> Aliases allow a string to be substituted for a word when it is >>>> used as >>>&g

Re: Having an alias and a function with the same name leads to some sort of recursion

>> Looking at the manual page, it says >> >> ALIASES >>Aliases allow a string to be substituted for a word when it is used >> as >>the first word of a simple command. Martin suggested (but IIUC didn't sent to this list): > "Beginning of a simple command" should probably be re

Re: number of bugs

There is a bug tracker at https://savannah.gnu.org/support/?group=bash. Dale

Re: "builtin jobs" does not output to stdout.

Chet Ramey writes: > Yes. As described in later messages, there is a special case that allows > the output of `jobs' to be piped. This came in at some point between > bash-1.05 (March 1990) and bash-1.08 (May 1991). I never extended this > special case to `builtin' or `command'. Is this (are thes

Re: Having an alias and a function with the same name leads to some sort of recursion

Robert Elz writes: > | Aliases are not used in bash scripts, unless bash is invoked in POSIX > | compatibility mode, or the "expand_aliases" shopt is turned on. > > I think that's what must have happened ... the infinite loop of > echo commands suggests that the function definition > > c

Re: [PATCH] local_builtin: do not overwrite previously saved options with local -

This is tricky. The documentation is If NAME is '-', the set of shell options is made local to the function in which 'local' is invoked: shell options changed using the 'set' builtin inside the function are restored to their original values when the function returns. It does

Re: unset does not remove functions like a[b] unless -f is specified

Greg Wooledge writes: > I'd be totally OK with restricting the function namespace a bit more. > Function names should not be allowed to contain backticks or less-than > or greater-than signs (in my opinion). I'm still undecided about > parentheses, but I'm leaning toward "denied". I'd be perfect

Re: unset does not remove functions like a[b] unless -f is specified

Emanuele Torre writes: > bash-5.1$ a[0] () { echo;} > bash-5.1$ unset 'a[0]' Admittedly, I'm running Bash 5.1.0, but the manual page says: fname () compound-command [redirection] function fname [()] compound-command [redirection] ...in posix mode, fname must

Re: More convenient tracing

Greg Wooledge writes: > On Wed, Jan 25, 2023 at 03:00:27PM -0500, Dale R. Worley wrote: >> >> Tracing with -x prints a lot of (usually) useless lines. >> >> $ bash -x ./tt >> [300+ lines of Bash initializations] >> + echo 'Now in tt.'

More convenient tracing

Some time ago I proposed a new option to Bash to cause it to trace commands (in the manner of -x) but not within the Bash initialization scripts. People advised me that this could be accomplished without a new option. I also picked up various suggestions for how to design it. This is my latest v

Re: Possible bug in bash

Greg Wooledge writes: > On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: >> Reading your message, I believe that the rule can be stated as follows, >> and I'd thank you to check it: && and || have the same precedence, and >> they both "as

Re: Handling files with CRLF line ending

It seems to me that there's more going on than first meets the eye. My understanding is that Posix's file open function allows specifying if the file is text or binary, and in text mode, if the underlying system natively uses CRLF for EOL, CRLF in the file is turned into LF for the code in a trans

Re: `declare -f "a="' fails unnecessarily

Andreas Schwab writes: >> In default mode, you actually can do >> $ function a=b { printf hi\\n; } >> though you can't execute it: >> $ a=b foo >> bash: foo: command not found > > You just have to quote any part of the function name upto the equal sign > to stop if from being interpret

Re: `declare -f "a="' fails unnecessarily

Emanuele Torre writes: > `declare -f "something="' fails with the following error: > > $ declare -f 'a=x' > bash: declare: cannot use `-f' to make functions > That error is not very useful. Bash makes `declare -f' fail with that > error when an argument looks like an assignment. It's an

Re: declare XXX=$(false);echo $?

Chet Ramey writes: > On 12/2/22 5:28 AM, Ulrich Windl wrote: >> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1") >> There is no indication in the manual page that "declare" ignores the >exit code of commands being executed to set values. > > Why do you think it should? `declare' h

Re: Bad leaks file fd to child processes

Greg Wooledge writes: > The fact that pvs *complains* about this instead of just ignoring it makes > it fairly unique. I don't know why the authors of pvs chose to do this. > Perhaps they were working around some known or suspected bug in some other > program that was commonly used as pvs's paren

Re: Bad leaks file fd to child processes

Alexey via Bug reports for the GNU Bourne Again SHell > Same behavior was in bash 4.4 (as well as now in bash 5.2): > > # echo $BASH_VERSION > 4.4.0(1)-release > # exec 66 # pvs > File descriptor 66 (/etc/hosts) leaked on pvs invocation. Parent PID > 1057606: ./bash > > But we use the fact tat ba

Re: Bad leaks file fd to child processes

"凋叶棕" via Bug reports for the GNU Bourne Again SHell writes: > I find that the file descriptor leaks when I execute the command pvs > in bash 5.2, The abnormal scenario is similar to the bug which > reported by > http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00026.html > > When I

Re: feature request: new builtin `defer`, scope delayed eval

The Go programming language has a "defer" statement which is used considerably for exactly this purpose. So we know that it's useful in practice. The question remains what is a good way to introduce it into Bash. As others have noted, there is already a "trap" with similar functionality. I'm no

Re: Found Bug and generated report using Bashbug

Chet Ramey writes: > On 9/5/22 6:13 PM, Aryan Bansal wrote: > >While testing how bash handles foreground and background processes > >using "&", I found out that the behaviour is sometimes undefined. The > >prompt sometimes prints just as the background process finishes executing > >resu

Re: test or [ does not handle parentheses as stated in manpage

Julian Gilbey writes: > Upgrading to bash 5.2.0(1)-rc2 did not help, neither did using \( > instead of (, and neither did putting spaces around the parentheses. It's ugly. The first point is that ( and ) are special characters and if unquoted are isolated tokens that have special syntax. So in

Re: Light weight support for JSON

Greg Wooledge writes: > The standard idiom for this sort of thing is > > eval "$(external-tool)" > > This means you need to *trust* the external-tool to produce safe code. True. And I use that idiom with ssh-agent routinely. But it still strikes me as unnatural. Dale

Re: Light weight support for JSON

The "obvious" way to support Json in Bash would be a utility that parses Json and produces e.g. a Bash associative array, and conversely a utility that reads a Bash associative array and produces Json. The real limitation is that it's difficult to have a subprocess set Bash's variables. As far as

Re: add custom environment variable in bash source code

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 "all the time

Re: local -r issue in conjunction with trap

Robert Stoll writes: > test1 # works as exit happens outside of test1 > test2 # fails with ./src/test.sh: line 6: local: readonlyVar: readonly > variable Beware that you haven't specified what you mean by "works" and "fails". I assume from the context that "fails" means "produces an error messag

Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty

Martin Schulte writes: > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) > seems to determine LINES and COLUMNS from stderr. It's not clear to me that the manual page says where the LINES and COLUMNS values are obtained from. Dale

Re: Arithmetic expression: interest in unsigned right shift?

Steffen Nurpmeso writes: > I realized there is no unsigned right shift in bash arithmetic > expression, and thought maybe there is interest. This would be difficult to define cleanly. Currently, arithmetic values are considered to be signed, and >> operates on them as such. So $ echo $(( 1

Re: Parallelization of shell scripts for 'configure' etc.

Paul Eggert writes: > In many Gnu projects, the 'configure' script is the biggest barrier to > building because it takes s long to run. Is there some way that we > could improve its performance without completely reengineering it, by > improving Bash so that it can parallelize 'configure' s

Re: Unfortunate error message for invalid executable

AA via Bug reports for the GNU Bourne Again SHell writes: > I.e., something like "I'm not sure what's going on, but your path > definitely exists, yet the kernel says otherwise." > > ... something like fprintf(STDERR,"No such file or directory while > attempting to execute %s (it exists, but can

Re: Unfortunate error message for invalid executable

Chet Ramey writes: > On 5/26/22 2:27 PM, AA via Bug reports for the GNU Bourne Again SHell wrote: >> When a user attempts to execute an executable that is not >> recognized as an executable by the system, the generated error is "No such >> file or directory" > > In this case, it's the errno valu

Re: Possible bug in bash

Robert Elz writes: > Note particularly that there is no operator precedence between > && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and || have the same precedence, and they both "

Re: bash 5.1 heredoc pipes problematic, shopt needed

Sam Liddicott writes: > Listed in the changes: > c. Here documents and here strings now use pipes for the expanded >document if it's smaller than the pipe buffer size, reverting >to temporary files if it's larger. > > This causes problems with many p

Re: Bash regexp parsing would benefit from safe recursion limit

willi1337 bald writes: > A deeply nested and incorrect regex expression can cause exhaustion of > stack resources, which crashes the bash process. Further, you could construct a deeply nested regex that is correct but would still crash the process. It's hard to define what should happen in a way

Re: Sus behaviour when cmd string ends with single backslash

vzvz...@gmail.com writes: > The mentioned bug is indeed fixed by this change. However, in case of > another edge case following new behaviour is observable: > > $ bash -c 'echo \' > \ > $ # backslash appears on output It's an interesting case, since the command that Bash is executing is e-c-h-o

Re: Zero-length indexed arrays

Lawrence Velázquez writes: > Did you mean to say that ${#FOO[*]} causes an error? Because > ${FOO[*]} does not, a la $*: The case that matters for me is the Bash that ships with "Oracle Linux". Which turns out to be version 4.2.46(2) from 2011, which is a lot older than I would expect. But it

Zero-length indexed arrays

A bit ago I was debugging a failing script at work. It turns out that when you say FOO=(x y z) then the variable FOO is an array and is defined. But when you say FOO=() then the variable FOO is an array (because ${#FOO[*]} substitutes an integer viz. 0) but it is *not* defined (because ${

Re: some.. bug .. ?

Alex fxmbsw7 Ratchev writes: > printf 'e=. ; (( $# > 1 )) && $e afile "${@:1:$# -1}"' >afile ; . afile 1 2 > 3 > > bash: : command not found This looks like another instance where you've constructed a command whose first word is the empty word. Try running with "set -x" and see what the command

Re: read -t0 may report that input is available where none is possible

More to the essence: $ read -t0

Re: coproc does not work with a lower case variable name

g...@as.lan writes: > Description: > coproc gives a syntax error if I try to use it with a lower case > variable name and a compound command: > bash: syntax error near unexpected token `}' > bash: syntax error near unexpected token `(' > > Repeat-By: > coproc bc { bc; } >

Re: bash conditional expressions

Mischa Baars writes: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; Well, looking at the manual page, I see -N file True if file exists and

Re: cmd completion.. normal that it doesnt complete dirs when cmds are available ?

Alex fxmbsw7 Ratchev writes: > i have a dir with some xbl*/ dirs and few xbl* commands ( via $PATH ) > i tried there xbl,tabtab but it only completed cmds > is this desired ? Naively, I would expect that when doing completion in the first position in a command, that the completion process will on

Re: Why should `break' and `continue' in functions not break loops running outside of the function?

Oğuz writes: >> It's a violation of scope. > > It's a violation of lexical scope, I'm asking why not implement > dynamic scope, what's wrong with it? Yes ... but the history of programming languages has been the history of learning that dynamic scoping is dangerous to program and lexical scoping

Re: Arbitrary command execution from test on a quoted string

elettrino via Bug reports for the GNU Bourne Again SHell writes: > The following shows an example of bash testing a quoted string and as > a result executing a command embedded in the string. > > Here I used the command "id" to stand as an example of a command. The > output of id on this machine w

Re: bash support for XDG Base Directory spec (~/.config/bash/)

Using XDG will have the complication that one normally sets environment variables like XDG_CONFIG_DIRS in ~/.bash_login. So I would add to the conversation, How much added value is there if XDG_CONFIG_DIRS is not used in practice? Dale

Re: ?maybe? RFE?... read -h ?

L A Walsh writes: > I know how -h can detect a symlink, but I was wondering, is > there a way for bash to know where the symlink points (without > using an external program)? My understanding is that it has been convention to use the "readlink" program for a very long time, so there's never been

Re: Interactive commands cant be backgrounded if run from bashrc

"C. Yang" writes: > This may be because the bashrc file is still running, and bash itself > perhaps does not finish initializing until everything in the bashrc > completes. This may be why CTRL+Z does not work correctly (it might > require bash to finish initializing first) I'm sure that's the pr

  1   2   >