Re: tab completing `/ cause weird errors messages.

On Sun, 26 Jun 2022 02:27:59 +0200, Emanuele Torre wrote: > Description: > Tab completing `/ (backtick-slash) causes bash to print lots of > weird error messages. FWIW, this happens for any path, even not terminated by slash, at least on my system: $ cat `/usr/ -l: bad substitution:

Re: Change in indirect expansion behavior from 4.4 to 5.0

On Tue, 29 Sep 2020 21:28:59 -0700, Jason Miller wrote: > Gentoo linux, GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu) > > On the above vesion of bash, the following script will not run the echo > command and print an error. On bash 4.4 it appears to treat the ${!foo} > the same as

Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

On Sat, 29 Aug 2020 15:25:44 -0400, Bruce Lilly wrote: > Unfortunately, because bash is GPL, I can't post the copyrighted script > which is covered by a non-GPL license. That's ridiculous. You don't have to post the whole script (neither should you), just a simple code snippet that shows the

Re: Expand first before asking the question "Display all xxx possibilities?"

On Thu, 6 Aug 2020 15:13:30 +0300, Ilkka Virta wrote: > I think they meant the case where all the files matching the given > beginning have a longer prefix in common. The shell expands that prefix > to the command line after asking to show all possibilities. > > $ rm * > $ touch

Re: bug in arithmetic expansion

On Sat, 9 Nov 2019 11:52:56 +0100, Joern Knoll wrote: > [tplx99]:/the/knoll > echo $((0123)) > 83 > [tplx99]:/the/knoll > echo $((123)) > 123 > [tplx99]:/the/knoll > echo $((01234)) > 668 > [tplx99]:/the/knoll > echo $((1234)) > 1234 If you want to force base 10 interpretation (remember that

Re: GNUbash v. 4.4.23-5 – Bash identifier location is non-correct in terminal

On Mon, 29 Oct 2018 11:40:54 +0100, Ricky Tigg wrote: > Component: bash.x86_64 4.4.23-5.fc29 @fedora > > To reproduce,: execute 'curl https://www.startpage.com'. > > Actual result: > > $ curl https://www.startpage.com > (...) [yk@localhost ~]$ > > Expected result: > > $ curl

Re: When reading less than wanted characters, "read" does not detect NUL bytes

On Fri, 15 Jun 2018 15:15:23 +0200, Davide Brini wrote: > So it looks like the only "reliable" way to detect NULs in the input is to > read one character at a time. Your explanation got me thinking, and I've come up with the following code that seems to be slightly more effici

Re: When reading less than wanted characters, "read" does not detect NUL bytes

On Fri, 15 Jun 2018 09:07:46 -0400, Greg Wooledge wrote: > On Fri, Jun 15, 2018 at 03:03:21PM +0200, Davide Brini wrote: > > $ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 2 var; do echo > > "read: $var, length: ${#var}"; done; } read: a, length: 1 > > read: ,

When reading less than wanted characters, "read" does not detect NUL bytes

Best explained with an example: $ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 1 var; do echo "read: $var, length: ${#var}"; done; } read: a, length: 1 read: , length: 0 read: , length: 0 read: b, length: 1 read: c, length: 1 This is as expected, and allows detecting a NUL in the input

Re: Backslashed space in variable/argument expansion does not prevent splitting.

On Fri, 17 Jun 2016 11:21:42 +0100, Dean Wakerley wrote: > Description: The expansion of a variable containing spaces splits on all > spaces including escaped/backslashed space. It's not a bug, you probably want eval ./echo_args.sh ${TCL_DEFS} but you're sitting on very

Re: bash hangs when using exec 2...

On Sat, 14 Mar 2015 15:17:24 +0100, kont...@marcbihlmaier.de wrote: Description: exec hangs up when using exec 2SOMETHING. Just tested on Ubuntu 14.04, Ubuntu 12.04, Debian7 working when just using exec 1SOMETHING Repeat-By: using in a script for logging

Re: Issues with exported functions

On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey chet.ra...@case.edu wrote: On 9/24/14, 3:44 PM, lolilolicon wrote: Personally, I have never needed this feature. I would vote for its removal: It's very surprising, creates bugs, and is not very useful. There are more things in heaven and

Re: Feature request - script directory

On Tue, 16 Sep 2014 21:02:54 +0200, Łukasz Wieczorek wieczorek1...@gmail.com wrote: I would like to propose a feature: a built-in/variable that returns/holds information about current script directory. This could help parsers to properly `source` files. Also please look how many people

Re: Substring Expansion does not work as intended

On Wed, 20 Aug 2014 15:05:48 +0200, eckard.bra...@gmx.de wrote: Description: Substring Expansion actually works different than manpage states, namely: If offset evaluates to a number less than zero, the value is used as an offset from the end of the value of parameter.

Re: Builtin 'read' data not saved

On Thu, 2 Jan 2014 11:35:11 -0800, P Fudd f...@ch.pkts.ca wrote: Here's some more oddities: =failing.sh: #!/bin/bash R=1|2 IFS='|' read -r A B $R echo A=$A, B=$B Expected: A=1, B=2 Actual: A=1 2, B= fail2.sh: #!/bin/bash R=1|2 while IFS='|' read -r A B; do echo

Re: Builtin 'read' data not saved

On Thu, 2 Jan 2014 11:35:11 -0800, P Fudd f...@ch.pkts.ca wrote: Here's some more oddities: Ok, the link I sent you is more about the issue you describe in your first message. See below for more on the new ones in this message. =failing.sh: #!/bin/bash R=1|2 IFS='|' read -r A B $R

Re: getting weird output out of 'echo' w/args

On Thu, 30 May 2013 08:53:48 +0300, Pierre Gaston pierre.gas...@gmail.com wrote: Missing quotes around [ ] can be nasty eg #!/bin/bash shopt -s nullglob # sounds a good idea! . . i=0 while read a[i++]; do echo ${a[i]} # why oh why nothing is printed! done hello It seems

Re: getting weird output out of 'echo' w/args

On Thu, 30 May 2013 16:56:36 +0800, Chris Down ch...@chrisdown.name wrote: Pierre is referring to the fact that [i++] is evaluated as a glob by the shell, the reason it doesn't work is because $i is postincremented instead of preincremented. You can see what he means here: $ shopt -u

Re: getting weird output out of 'echo' w/args

On Thu, 30 May 2013 17:06:08 +0800, Chris Down ch...@chrisdown.name wrote: That's... why I said he was unintentionally doing postincrement... Doh! Indeed you said that. Apologies for reading too fast. -- D.

Re: Bash stating it is in a directory which does not exist

On Tue, 19 Feb 2013 17:00:32 +1100, Nikolas Kallis n...@nikolaskallis.com wrote: Hello, I have found a bug in Bash: /opt/foobar$ /opt/foobar$ rmdir ../foobar/ /opt/foobar$ With the above, one can see I deleted the directory 'foobar/' from within the directory itself. What one

Re: problem with extended regular expression in bash 4.1

On Mon, 26 Nov 2012 15:03:35 +0100, Davide Brini dave...@gmx.com wrote: On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote: It changed between bash 3.1 and 3.2, documented in the NEWS file. There is a compat31 option that can be turned on to restore the 3.1

Re: problem with extended regular expression in bash 4.1

On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote: It changed between bash 3.1 and 3.2, documented in the NEWS file. There is a compat31 option that can be turned on to restore the 3.1 behavior. As you see it works for me in 3.25 Then maybe you have the compat31

Re: problem with extended regular expression in bash 4.1

On Sat, 24 Nov 2012 21:08:16 +, Alex Chupin (achupin) achu...@cisco.com wrote: Dear All, Can someone shed light on the difference in behaviour of bash 4.1. and 3.25? I am out of ideas. Regards, Alexander Chupin $ bash --version; s=12345;if [[ $s =~ '^[0-9]+$' ]]; then echo it is

Re: Incorrect mangling of multiline array assignment in history

On Thu, 07 Jun 2012 12:54:28 -0400, Chet Ramey chet.ra...@case.edu wrote: On 6/4/12 12:42 PM, Davide Brini wrote: Bash Version: 4.2 Patch Level: 29 Release Status: release Description: To insert them in the history, bash converts multiline commands into a single line

Incorrect mangling of multiline array assignment in history

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-unknown-linux-gnu' -DCONF_VENDOR='unknown'

Re: Bug, or someone wanna explain to me why this is a POSIX feature?

On Mon, 08 Aug 2011 12:07:21 -0700, Linda Walsh b...@tlinx.org wrote: however, Can you explain the purpose of the shopt option 'no_empty_cmd_completion' and if you can do that, can you explain why I shouldn't use tab as an indent char on an empty line...? Short answer: if you do foo() {

Re: Bug, or someone wanna explain to me why this is a POSIX feature?

On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini dave...@gmx.com wrote: In fact, you could do the same thing with foo() { # hit tab here and I'm sure you wouldn't consider that an empty line. I have to take that back: it looks like bash treats the above differently depending on whether

Re: How to do? Possible?

On Mon, 25 Jul 2011 14:28:52 -0700, Linda Walsh b...@tlinx.org wrote: Not really. It only seems that way because within () any $ is usually expanded BEFORE the () starts from the parent You can see this by GLOBAL=hi there (echo $GLOBAL) prints out hi there as expected,

Re: When double quote is considered when not?

On Wednesday 30 Mar 2011 11:13:58 ali hagigat wrote: The following scripts were run for /bin/bash, version 4.0.33, and then comes their outputs. In the second example seems to have a warning: binary operator expected. Why the error is generated? and why there is no error for the first

Re: bash tab variable expansion question?

On Friday 25 Feb 2011 05:15:24 Eric Blake wrote: On 02/24/2011 03:14 PM, Michael Kalisz wrote: $ echo $PWD/TAB will expand the $PWD variable to your current directory while in bash, version 4.2.0(1)-release: $ echo $PWD/TAB will just escape the $ in front of the $ variable i.e:

Re: Strange bug in arithmetic function

On Monday 21 Feb 2011 09:13:54 Marcel de Reuver wrote: In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if the week number is even. Only in week 08 the error is: bash: 08: value too great for base (error token is 08) the same in week 09, all others are Ok... It's not a bug.

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

On Thu, 17 Feb 2011 22:35:31 +0800 Clark J. Wang dearv...@gmail.com wrote: On Thu, Feb 17, 2011 at 9:20 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: See following script output: bash-4.2# cat quoted-pattern.sh [[ .a == \.a* ]] echo 1

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

On Thu, 17 Feb 2011 22:56:21 +0800 Clark J. Wang dearv...@gmail.com wrote: On Thu, Feb 17, 2011 at 7:09 PM, Clark J. Wang dearv...@gmail.com wrote: See following script output: bash-4.2# cat quoted-pattern.sh [[ .a == \.a* ]] echo 1 # not quoted [[ aa =~ \.a* ]] echo 2 # quoted

Re: Why sh does not return a false value?

On Sat, 5 Feb 2011 16:17:05 +0330 ali hagigat hagigat...@gmail.com wrote: if (sh -c exit 34) then echo p;fi p The following condition should be false, because our exit value is non-zero. but 'if' considers the condition as true and executes 'echo' command. Why? Try if (sh

Re: question about exit command

On Wednesday 19 Jan 2011 10:42:21 ali hagigat wrote: I have two script files and I execute them as follows: - #script1 echo ppp exit 0 echo qqq /root ./script1 ppp - #script2 if (exit 0) then echo ppp fi

Re: How is $string translated?

On Mon, 30 Aug 2010 14:30:45 +0300 Pierre Gaston pierre.gas...@gmail.com wrote: On Mon, Aug 30, 2010 at 1:35 PM, Clark J. Wang dearv...@gmail.com wrote: The Bash manual says: A double-quoted string preceded by a dollar sign ($) will cause the string to be translated according to the

Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~

On Wednesday 04 Aug 2010 09:06:16 Linda Walsh wrote: On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote: On Sun, 1 Aug 2010, Linda Walsh wrote: I have: w=/home/law/bin/package: line 5: type: xx: not found The =~ operator is suppose to use the RH Expr as a ext.-regex. So why doesn't

Re: The usage of [[ (not with if)

On Wednesday 04 Aug 2010 16:03:25 Peng Yu wrote: I have the following script and output. The man page says Return a status of 0 or 1 depending on the evaluation of the conditional expression expression. Therefore, I thought that the two printf statements should print 1 and 0 respectively.