Re: Likely Bash bug

On Wed, 17 Mar 2021 at 23:05, Greg Wooledge wrote: > On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote: > > | Operating system is BionicPup64 8.0. > > That might. More importantly is probably whatever package management > > system it uses. I have no idea what the "ash" the bug rep

Re: Possible bug with redirect.

On Tue, 2 Nov 2021 at 02:37, Rikke Rendtorff wrote: > > I'm very new to linux [...] > I went to the https://linuxmint.com community website and joined their IRC > chat to see if they had an explanation and they told me it may be a bug, > since they couldn't reproduce it for other commands. > > P

Re: Unclosed quotes on heredoc mode

On Wed, 24 Nov 2021 at 14:36, Martijn Dekker wrote: > There's a regularly updated mirror of the bash repo here: > https://github.com/bminor/bash/ Or if you care about software freedom you might prefer: https://git.savannah.gnu.org/cgit/bash.git

Re: Long variable value get corrupted sometimes

On Wed, 16 Feb 2022 at 19:38, Daniel Qian wrote: > I encountered a problem that long variable value get corrupted sometimes. > A UTF-8 encoded file containing a lot of Chinese characters, file size ~35K. > FOO=$(cat /tmp/foo.txt) Hi, this looks like something that was recently fixed, perhaps y

Re: the "-e" command line argument is not recognized

On Wed, 16 Feb 2022 at 19:51, Viktor Korsun wrote: > produced output: > ./get_env.sh > -q > -w > > -r > -t > -y > > expected output: > ./get_env.sh > -q > -w > -e > -r > -t > -y Hi, this behaviour is well known history and widely discussed. You can search the web for "printf vs echo bash" and yo

Re: Possible bug in bash

On Fri, 13 May 2022 at 18:18, flyingrhino wrote: > Before opening the bug I looked online for if-then-else vs [[ and no > proper information was available, definitely not to the extent you explain > here. Have a look here: http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3 >

Re: Revisiting Error handling (errexit)

On Mon, 4 Jul 2022 at 22:22, Yair Lenga wrote: > I've tried to look into a minimal > solution that will address the most common pitfall of errexit, where many > sequences (e.g., series of commands in a function) will not properly > "break" with 'errexit'. For example: > > function foo { > cat

Re: [bash 4] 'test -v 1' is never true

On Mon, 28 Nov 2022 at 00:01, Alejandro Colomar wrote: > On 11/27/22 12:41, Alexey wrote: > > On 2022-11-26 21:45, Alejandro Colomar wrote: > > I could suggest you to use for clarity another construction: > > [[ ${1+isset} ]] || echo "not set" > > Here "isset" is just for readability. You could

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

On Fri, 2 Dec 2022 at 21:29, 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. The above is not surprising at all. 'declare' is a bu

Re: Segmentation Fault in bash --posix

On Sat, 21 Jan 2023 at 09:24, N R wrote: > I ran into a segmentation fault running bash --posix. Here are the > steps to reproduce : > bash-5.1$ echo () { echo test } > > echo test > > } > bash-5.1$ echo > Even though I'm not sure what is causing this seg fault, I'm sure i

Re: Vulnerability Report(No SPF Record)

On Fri, 17 Feb 2023 at 07:42, Greg Wooledge wrote: > On Thu, Feb 16, 2023 at 07:21:14PM -, Syed Maaz wrote: > > I am a security researcher,I have found this vulnerability related to > > your website bash-hackers.org. > Just for the record, "bash-hackers.org" is a third-party web site, n

Re: error message lacks useful debugging information

On Fri, 6 Oct 2023 at 01:20, Ángel wrote: > On 2023-10-04 at 20:05 -0400, Dave Cigna wrote: > > Here's how I encountered the problem. You might not be able to > > reproduce > > it on your machine, but that doesn't mean that it's not a bug with > > bash: > > > > download: candle_1.1.7.tar.gz > >

Re: BUG: Colorize background of whitespace

terminal window so that they are not visible, then the '\t' characters then get the expected blue background. I see this in Debian 11, both in 'lxterminal' under LXDE, and in the virtual consoles, [david@kablamm ~]$ echo $BASH_VERSION 5.1.4(1)-release [david@kablamm ~]$ cat /etc/debian_version 11.8

Schily ueber Deutschland

Lese selbst: http://www.heise.de/newsticker/meldung/59427 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Deutsche Buerger trauen sich nicht ...

Auslaenderbanden terrorisieren Wahlkampf - deutsche Buerger trauen sich nicht ihre Meinung zu sagen! Weiter auf: http://www.npd-nrw.net/aktuelles/03_2005/ak_presse_nrw_1603.htm Auslaender ueberfallen nationale Aktivisten: http://www.npd.de/npd_info/meldungen/2005/m0505-13.html http://www.npd.de

Re: Code Execution in Mathematical Context

On Thu, 6 Jun 2019 at 03:40, Ilkka Virta wrote: > On 5.6. 17:05, Chet Ramey wrote: > > On 6/4/19 3:26 PM, Ilkka Virta wrote: > > >>$ echo "$(( 'a[2]' ))" > >>bash: 'a[2]' : syntax error: operand expected (error token is "'a[2]' ") > > > > The expression between the parens is treated as if

Re: T/F var expansion?

On Mon, 29 Jul 2019 at 14:18, L A Walsh wrote: > > Is there a T/F var expansion that does: [...] > > Sorry if this is already implemented in some form, I'm just > not remembering there being one. Your message is not a bug report. The list help-b...@gnu.org> exists to help with questions like

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

n Thu, 11 Jul 2024 at 22:14, David Hedlund wrote: > When a directory is deleted while the user is inside it, the terminal > should automatically return to the parent directory. Hi, I disagree, and I think if you understand better why this occurs, you will understand why knowledgable user

LINENO is affected by sync

Version: GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf) Raspberry Pi using Raspbian. Installed from repo? LINENO goes backwards when run sync echo "== At this point \$LINENO has correctly counted about 2800 lines=test @ 2832 $LINENO

Re: LINENO is affected by sync

's going to be anything simple like that. This happens again at intervals - wrong by different small numbers I think - weirdly enough the next time it happens is also near a 'sync' operation - which is what misled me. Anyway - apologies for the red herring any suggestion welcome. Do t

Re: LINENO is affected by sync

l need to put money where mouth is on that. I will put some effort into minimising the content of an example - but starting with 2800 lines that could be much effort. Thanks David On Wed, Sep 1, 2021 at 6:09 PM Greg Wooledge wrote: > On Wed, Sep 01, 2021 at 04:52:29PM +0100, David Collier wrote:

Interesting bug

u) Fedora 32: GNU bash, version 5.0.17(1)-release (x86_64-redhat-linux-gnu) (Probably more, these were the only two I tested.) Happy bug hunting! Best Regards David#!/bin/bash function badCode { echo "bad code executed" } function testCode { #pick some existing file echo "/etc/passwd&

Re: Interesting bug

I guess 99% of programmers would either expect "Finished" to be printed or some syntax error. Well, 99% of shell programmers will (hopefully ;-) ) put a blank between "{" and "echo" in the line foo="$(testCode)" || {echo "foo";} Yes, the interesting part is that depending on which space you

Re: Interesting bug

P.S.: Also, if you remove the case/esac from the original example, it'll result in a syntax error. So why can the case/esac be used to ignore the syntax error? smime.p7s Description: S/MIME Cryptographic Signature

Re: Interesting bug

Thanks a lot for the detailed explanations, much appreciated! So essentially it's no bug - just a rather uncommon choice of keywords. I still don't agree with that choice since it can be abused to somewhat hide code in pull requests to less experienced maintainers, but oh well... there's proba

Bash reference manual feedback

24. Perhaps change "ofthe" to "of the". * Bash implements the ! keyword to negate the return value of a pipeline (see {Pipelines}). Very useful when an if statement needs to act only if a test fails. The Bash ‘-o pipefail’ option to set will cause a pipeline to return a failure status if any command fails. 25. Should this be 2 separate list items? Commands specified with an RETURN trap are executed before execution 26. Perhaps change "an" to "a". Thank you. David

Bash reference manual feedback

that this usage is deprecated I was so surprised to find the "’" character (Unicode 0x2019) here that I assumed that it should be some other character (perhaps "'"). I have not managed to get the warning message, so I still do not understand this item properly. Thank you. David

echo "${HOME#$*/}" segfaults

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

Bash

I am new to Ubuntu and Linux. I am trying to install Bash Shell and I get this error and cannot find a solution. When I type make install I get this error. If you can give a direction to head in to correct this, i would appreciate it. thanks Dave mkdir -p -- /usr/local/share/man/man1 mkdir: canno

Bash associative arrays are slow, don't scale

d be helpful if the man page stated that bash arrays are O(N) in performance for large N. Had I known that, I wouldn't have relied on using bash at all for such kind of script. cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B

edit-and-execute-command is appropriately named, weird

Hi all, In using bash over the years, I've been quite happy to be able to hit ctrl-x ctrl-e to pull up an editor when my input has grown too complicated. When using read -e for input, however, the behavior I find makes a lot less sense: the input line is still opened in an editor, but the result

Re: edit-and-execute-command is appropriately named, weird

short term, I was able to get the behavior I want by overriding fc in the script in question, but I still think default behavior is ugly. Thanks again for the response, and I'm interested in your further thoughts. - David On Thu, May 26, 2011 at 9:09 AM, Chet Ramey wrote: > On 5/23/11 1

Re: edit-and-execute-command is appropriately named, weird

my home internet is hooked up (which should be any day now...). On Sat, May 28, 2011 at 3:42 PM, Chet Ramey wrote: > On 5/27/11 6:20 PM, David Thomas wrote: >> Hi Chet, >> >> Thank you for the response, and the attempt at assistance. >> >> I was unaware of the POS

Memory leak with associative arrays

Version: GNU bash, version 4.2.8(1)-release (x86_64-pc-linux-gnu) on Ubuntu 10.04 If I set an associative array, as in: MYARRAY["something"]="Goobledygook" Then I set that same variable name again later (and so on in a loop). The earlier variables are never released from memory, before I re-set

RE: Memory leak with associative arrays

Great stuff, amazingly fast - I'm really surprised! Thanks for that. Dave -Original Message- From: bug-bash-bounces+davidparks21=yahoo@gnu.org [mailto:bug-bash-bounces+davidparks21=yahoo@gnu.org] On Behalf Of Chet Ramey Sent: Tuesday, October 04, 2011 5:29 PM To: David Par

bash-4.2: poor order of conditionals

You might be better off with while (i < file_size && buffer[i] != '\n') i++; Regards David Binderman

Re: '>; ' redirection operator [was: [1003.1(2008)/Issue 7 0000530]: Support in-place editing in sed (-iEXTENSION)]

cc: ebl...@redhat.com bug-bash@gnu.org d...@vger.kernel.org miros-disc...@mirbsd.org Subject: Re: '>;' redirection operator [was: [1003.1(2008)/Issue 7 530]: Support in-place editing in sed (-iEXTENSION)] > On 12/22/2011 08:39 AM, David Korn wrote: > > Su

Re: Edit vs delete a running script. Why difference?

On Jan 18, 5:22 am, Greg Wooledge wrote: > On Wed, Jan 18, 2012 at 01:19:20PM +0900, Teika Kazura wrote: > > If the > > entire script is read at invocation, then why should / does > > modification affect? Is it a bug? > > The entire script *isn't* read at invocation.  Bash just reads a little > bi

Bug with print-completions-horizontally

line? */ if (matches[i+1]) { - if (i && (limit > 1) && (i % limit) == 0) + if (i % limit == 0) { rl_crlf (); lines++; With best regards from David Kaasen.

why does errexit exist in its current utterly useless form?

I recently worked on a project involving many bash scripts, and I've been trying to use errexit to stop various parts of a script as soon as anything returns a non-0 return code. As it turns out, this is an utterly useless endeavour. In asking this question on this forum, I hope somebody out the

Re: why does errexit exist in its current utterly useless form?

On Friday, December 14, 2012 6:23:41 PM UTC-5, Eric Blake wrote: > Short answer: historical compatibility. 'set -e' has been specified to > behave the way it did 30 years ago in one reference implementation, and > while you can argue till you are blue in the face that the reference > implementatio

Re: why does errexit exist in its current utterly useless form?

On Saturday, December 15, 2012 5:23:04 PM UTC-5, Chet Ramey wrote: > There is already a proposal for a new option similar to what you want; you > can read the discussion at > > http://austingroupbugs.net/view.php?id=537 Thank you for all the references, I'll have a look!

eval doesn't close file descriptor?

With the script below, I'd expect any fd pointing to /dev/null to be closed when the second llfd() is executed. Surprisingly, fd 3 is closed, but fd 10 is now open, pointing to /dev/null, as if eval copied it instead of closing it. Is this a bug? Thanks, M $ bash -c 'llfd () { ls -l /proc/$BA

Re: eval doesn't close file descriptor?

Ok, but I see the same behaviour when eval runs in a subshell: $ bash -c 'llfd () { echo "pid:$BASHPID" >&2; ls -l /proc/$BASHPID/fd/ >&2; }; x=3; eval "exec $x>/dev/null"; llfd; echo | eval "llfd $x>&-"' [same output, fd 10 open, pointing to /dev/null, even though it's a subshell] $ bash -c 'llf

Re: eval doesn't close file descriptor?

hy would I want the fd in a variable otherwise.) Too bad the "natural" syntax 'llfd $x>&-' doesn't work, but I guess this will do. On Tue, Feb 12, 2013 at 11:12 AM, Greg Wooledge wrote: > On Tue, Feb 12, 2013 at 11:07:06AM -0500, Matei David wrote: > > On a d

Re: eval doesn't close file descriptor?

hich are not copied across subshells; like 60&63 3. fds which are copied across subshells, but not exec; like 10 I knew about types 1&2, but not about type 3. Apparently with your first suggestion, fd 10 is created and survives a subshell creation. Is this correct?? On Tue, Feb 12, 20

Re: eval doesn't close file descriptor?

o on this subject. Thanks, M On Tue, Feb 12, 2013 at 2:50 PM, Chet Ramey wrote: > On 2/12/13 2:07 PM, Matei David wrote: > > > ... there seem to be not 2 but 3(!) types of file descriptors: > > 1. fds which are copied across both subshells and exec; like 4 > > 2. fds wh

Re: eval doesn't close file descriptor?

Thank you for the explanation. On Tue, Feb 12, 2013 at 8:32 PM, Chet Ramey wrote: > On 2/12/13 11:40 AM, Pierre Gaston wrote: > > On Tue, Feb 12, 2013 at 6:07 PM, Matei David > wrote: > > > >> Ok, but I see the same behaviour when eval runs in a subshell: > >

Re: eval doesn't close file descriptor?

2:28 8 -> /proc/4520/auxv cat: /dev/fd/63: No such file or directory $ Note how 63 is open before '(echo)' and closed after. Is this expected? On Wed, Feb 13, 2013 at 12:06 PM, Matei David wrote: > Thank you for the explanation. > > > On Tue, Feb 12, 2013 at 8:32 PM, Ch

read builtin. input processes improperly inheriting IFS setting

From: David H. To: bug-bash@gnu.org,b...@packages.debian.org Subject: read builtin. input processes improperly inheriting IFS setting Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCON

i++ cause bad return code when result is 1

% uname -a Linux dph1d1ods13 2.6.32-279.2.1.el6.x86_64 #1 SMP Thu Jul 5 21:08:58 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux % bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) The ((i++)) fails only when the result is 1. When the result is 0 or 2, it do

failed grep should cause subshell to exit

### should never see done ** ** % uname -a Linux x 2.6.32-279.2.1.el6.x86_64 #1 SMP Thu Jul 5 21:08:58 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux % bash --version GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) ( set -ex ** ** echo hello >x grep hello x

Re: i++ cause bad return code when result is 1

error code. ...IMHO, of course. On Mon, Aug 19, 2013 at 7:40 AM, Greg Wooledge wrote: > On Mon, Aug 19, 2013 at 05:50:31AM +0200, Chris Down wrote: > > On 2013-08-18 16:57, David Lehmann wrote: > > > The ((i++)) fails only when the result is 1. When the result is 0 or >

Re: failed grep should cause subshell to exit

Andreas, I expected the '!' to reverse the exit code, such that if the grep return 0 (success), the expression would return 1 (failure); if the grep returned non-zero (failure), the expression would return 0 (success). i.e. I expected the '!' to behave like it does in C.

C-style escapes within substitution expansion

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash

bash-4.3 bug report

Hello there,  [bind.c:2238]: (style) Array index 'j' is used before limits check. Source code is   for (j = 0; invokers[j] && j < 5; j++) Suggest new code   for (j = 0; (j < 5) && (invokers[j] != NULL); j++) Regards David Binderman

RE: bash-4.3 bug report

hen* sanity check it's value. Regards David Binderman

Empty sub-string expansion bug

Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash

Problem with declare -a using a subcommand that parses data containing ctrl-A characters.

IVE:2:0:0:0:0:0:0:0:0:0:10.2.2.11:10.2.2.12:1 mhost1:/dev/ttyS1:TTY:38400:349:350:ALIVE:0:0:2:0:0:0:0:20:48892:48812:(null):(null):99' declare -a COMC=($(echo $t1 | head -n1 | awk -F: '{print $1,$2,$3}')) Repeat-By: #!/bin/bash # # Test created by David B. Anderson dband

Problem with declare -a using a subcommand that parses data containing ctrl-A characters.

IVE:2:0:0:0:0:0:0:0:0:0:10.2.2.11:10.2.2.12:1 mhost1:/dev/ttyS1:TTY:38400:349:350:ALIVE:0:0:2:0:0:0:0:20:48892:48812:(null):(null):99' declare -a COMC=($(echo $t1 | head -n1 | awk -F: '{print $1,$2,$3}')) Repeat-By: #!/bin/bash # # Test created by David B. Anderson dband

Problem with declare -a using a subcommand that parses data containing ctrl-A characters.

IVE:2:0:0:0:0:0:0:0:0:0:10.2.2.11:10.2.2.12:1 mhost1:/dev/ttyS1:TTY:38400:349:350:ALIVE:0:0:2:0:0:0:0:20:48892:48812:(null):(null):99' declare -a COMC=($(echo $t1 | head -n1 | awk -F: '{print $1,$2,$3}')) Repeat-By: #!/bin/bash # # Test created by David B. Anderson dband

strange bash state adds forward slash '/' after tab-completed executables

Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VE$ uname output: Linux scooter 2.6.18-4-scooter #1 SMP S

Re: \w in PS1 hopelessly confuses bash in workdir ending in \

07" \007 [EMAIL PROTECTED]:/tmp/xxx\$ echo -e "\007"  [EMAIL PROTECTED]:/tmp/xxx\$ echo "${PWD/$HOME/~}\007" /tmp/xxx\\007 [EMAIL PROTECTED]:/tmp/xxx\$ echo -e "${PWD/$HOME/~}\007" /tmp/xxx\007 Since PWD can contain backslashes at arbitrary positions, echo -e is clearly inappropriate here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

'read' primitive

From: dlutolf To: bug-bash@gnu.org,[EMAIL PROTECTED] Subject: [50 character or so descriptive subject here (for reference)] Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DC

Fwd: Re: Bash bug --- 1st parameter substitued for /InstallShield/ that is passed to the main entry pt of program

t 09:50PM, "Paul Jarc" <[EMAIL PROTECTED]> >> wrote: >>>david bone <[EMAIL PROTECTED]> wrote: >>>> The parameters passed to the ``main entry'' of a program substitutes >>>> the first parameter "/*hi*/" which is a c++ type co

Bug in array populating does not respect quotes

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDI$ uname output: Linux bristol 2

Re: Bug in array populating does not respect quotes

Thank you for all and sorry for the noise, you were right. David. On Thu, Sep 24, 2009 at 6:38 PM, Chris F.A. Johnson wrote: > On Thu, 24 Sep 2009, David Martin wrote: > >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: li

Failed bash -r command returns 0 exit status

bash: /bin/ls: restricted: cannot specify `/' in command names 1 $ bash --restricted -c "/bin/ls && /bin/ls"; echo $? bash: /bin/ls: restricted: cannot specify `/' in command names bash: /bin/ls: restricted: cannot specify `/' in command

RE: Failed bash -r command returns 0 exit status

sh: /bin/ls: restricted: cannot specify `/' in command names 1 It's the combination of commands that causes problems. Chet Ramey has acknowledged this as a bug. In the meantime, can anyone suggest a workaround? Regards, David Pitt | Developer/Designer TI SD Risk Systems | Technology So

RE: Failed bash -r command returns 0 exit status

Thanks Chet! David Pitt | Developer/Designer TI SD Risk Systems | Technology Solution Delivery | OTSS >Level 3 Core A 833 Bourke Street Docklands VIC 3008 >Australia and New Zealand Banking Group Ltd | www.anz.com > -Original Message- From: Chet Ramey [mailto:chet.ra...@case.e

bash(1): please fix a few typos and some style stuff

around line 50 and some other stuff along the document. I'm willing to try and help on this stuff if you are to consider it. Note that we will be glad if you decided to sheep directly the French translation of manual pages upstream. Cheers David --- bash.1 2010-07-29 15:42:42.0 -0400 +

Wildcard expansion in $PATH

: "MANPATH items can now be set with an asterisk, which indicates that all possible dir-names are to be searched." Such a feature for BASH would be quite nifty :-) If there is a patch for this, I'd appreciate anyone pointing me in the appropriate direction.

bash crashed after experimenting with $TERM

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./includ

Vorbildliche Aktion

Lese selbst: http://www.npd.de/npd_info/deutschland/2004/d1204-24.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: question on retrieving map(-A) value w/indirect name

On 17 March 2018 at 20:40, L A Walsh wrote: > > I seebut that begs the question, how do you access an array's > members using a var holding the array's name? > > I wanted to be able to do something like have a set of > values in an assoc. map, and pass the name to a generic > processing routin

Re: question on retrieving map(-A) value w/indirect name

On 17 March 2018 at 11:50, L A Walsh wrote: > > I'm a bit confused ... > If I have assoc-array: > > declare -A foo=([one]=11 [two]=22) > > and am passing name in another var, like "fee" > > fee=foo > > I tried echoing the val: > > echo ${!fee[one]} > > but got nothing -- tried a few other synta

Re: PDF documentation output not readable (3.2.6 GNU Parallel)

On 11 May 2018 at 07:35, Quentin L'Hours wrote: > On 2018-05-10 02:24 PM, Greg Wooledge wrote: >> Oh... well, it's not in the manual (bash(1)). It's in this >> other thing called the "Bash Reference Manual", apparently at >> > > Th

Re: suggestion for improvement - help pwd

On 3 June 2018 at 09:54, Chet Ramey wrote: > On 6/2/18 2:19 PM, jefg...@protonmail.com wrote: >> Dear Sir or Madam, >> >> I'd like to make a somewhat meticulous suggestion for improvement in the >> output of 'help pwd'. >> On line 6, the word 'directory' is not properly indented. > > It looks fin

Looking for key-bound auto-completed arg buffer in readline/bash.

are one and only commands, so history is useless.) This doesn't seem like it would be hard to do (famously dangerous words), and present it here. David Weeks Information Developer -- Making technology useful.

patchset to optionally disable function exports

From 9f8f691304329618556c8c33dfc0b30cd10fcf26 Mon Sep 17 00:00:00 2001 From: David Galos Date: Thu, 25 Sep 2014 13:27:43 -0400 Subject: [PATCH 1/4] add a flag to enable or disable function import on startup --- configure.in | 6 ++ variables.c | 4 2 files changed, 10 insertions(+) diff --

Re: REGRESSION: shellshock patch rejects valid function names

I fixed the bug in ksh that allows you delete a special builtin. On Mon, Sep 29, 2014 at 5:25 PM, Dan Douglas wrote: > Just a few points to add. > > On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote: > > 2014-09-29 09:04:00 -0600, Eric Blake: > > [...] > > > > "The function is

The restricted shell can be easily circumvented.

Bash Bug Report Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='p$uname output: Linux LFS-BUI

first trap call behaviour

p within a function the first time, but not subsequently. Example script and output below Thanks David Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_

Bogus value of variable BASH

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

Re: Bogus value of variable BASH

ond of Ubuntu's pointing /bin/sh to dash rather than bash. That seems sacrilegious, in my opinion. David Hunt On 2/9/16, Chet Ramey wrote: > On 2/8/16 7:09 PM, David Hunt wrote: > >> Bash Version: 4.3 >> Patch Level: 11 >> Release Status: release >> >> Descri

Bug in syntax checking causes unintended running of a function

Hi! I found a bug in bash, I've checked versions 4.1 (centos 6.7), 4.2 (centos 7.2), and 4.3.30 (from the ftp site). The bug is that if you do a double parenthesis math thing with the wrong syntax, the script runs the function during what I assume is syntax checking. Demonstration script is attache

Bug in syntax checking causes unintended running of a function

The behavior of bash in this instance could cause a serious problem. - David On Mon, Apr 18, 2016 at 8:38 PM, konsolebox > wrote: > On Tue, Apr 19, 2016 at 3:52 AM, David Maas > wrote: > > Hi! I found a bug in bash, I've checked versions 4.1 (centos 6.7), 4.2 > > (centos

Re: Bug in syntax checking causes unintended running of a function

function with a scope) to work. Anyway if you guys don't want to fix it, I doubt that many people would notice, but it is definitely a bug! Thank you for discussing it, David On Wed, Apr 20, 2016 at 12:55 AM, konsolebox wrote: > On Tue, Apr 19, 2016 at 10:45 PM, David Maas wrote: >

Re: Bug in syntax checking causes unintended running of a function

Incidentally, is it possible that somehow )) is simply interpreted the same as } in this situation? It would also explain the perceived behavior. On Wed, Apr 20, 2016 at 12:55 AM, konsolebox wrote: > On Tue, Apr 19, 2016 at 10:45 PM, David Maas wrote: > > Running the echo and other co

Re: Bug in syntax checking causes unintended running of a function

Fair enough. On Wed, Apr 20, 2016 at 8:44 AM, Greg Wooledge wrote: > On Wed, Apr 20, 2016 at 08:30:48AM -0700, David Maas wrote: > > So if you really want my opinion, the shell should be aware that it's in > a > > function. > > Agreed, unless it's really ha

Process substitution can leak CTLESC (0x01) in output

x27;) # Expected output: 01 # Actual output: 01 (good) echo -n $'\x01' | od -An -t x1 # Expected output: 7f # Actual output: 7f (good) echo -n $'\x7F' | od -An -t x1 --%< snip %<-- I've tested this on both 4.3.46(1)-release as provided by my OS vendor, and a 4.4.12(21)-release which I built from source. David

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

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux blues-System-Pr

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

On 2024-07-12 00:54, Lawrence Velázquez wrote: On Thu, Jul 11, 2024, at 6:08 PM, David Hedlund wrote: Expected behaviour When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. ``` user@domain:~/test$ mkdir ~/test &

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

On 2024-07-12 04:19, David wrote: n Thu, 11 Jul 2024 at 22:14, David Hedlund wrote: When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. Hi, I disagree, and I think if you understand better why this occurs, you will

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

On 2024-07-12 15:10, Chet Ramey wrote: On 7/11/24 9:53 PM, David Hedlund wrote: Thanks, Lawrence! I found this discussion helpful and believe it would be a valuable feature to add. Can I submit this as a feature request? I'm not going to add this. It's not generally useful for i

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

On 2024-07-16 15:31, Lawrence Velázquez wrote: On Tue, Jul 16, 2024, at 3:47 AM, David Hedlund wrote: Do you think that it would be appropriate to submit this feature request to the developers of the rm command instead. How would this help? The rm utility cannot change the working directory

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

On 2024-07-19 07:30, Martin D Kealey wrote: TL;DR: what you are asking for is unsafe, and should never be added to any published version of any shell. On Tue, 16 Jul 2024 at 17:47, David Hedlund wrote: Do you think that it would be appropriate to submit this feature request to the

Re: fg via keybind modifies tty settings

bash version `GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)`) Den lör 12 okt. 2024 kl 10:04 skrev Lawrence Velázquez : > On Sat, Oct 12, 2024, at 2:22 AM, David Moberg wrote: > > So this kind of bugfix is not enough to ever trigger a new release on its > > own? (soun

Re: fg via keybind modifies tty settings

Has anyone been able to take a more deep look? Where in the bash source code would this happen? I learned that fish resets these kind of settings quite often. Den tis 24 sep. 2024 16:21Chet Ramey skrev: > On 9/20/24 7:23 PM, David Moberg wrote: > > > Bash Version: 5.2 > &g

Bash debugging.

above the ARGC value (1) says this is the argument #?# 2 -X appears to be a dummy unused argument #?# 3 Let me know what you think? David Shuman

  1   2   >