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: no
On Fri, 24 Dec 2010 13:20:55 +0500 Коренберг Марк
wrote:
> GOOD CASE:
> mma...@mmarkk-work:/tmp$ echo aaa > /tmp/test1
> mma...@mmarkk-work:/tmp$ read x < /tmp/test1 && echo success
> success
> mma...@mmarkk-work:/tmp$ echo $x
> aaa
> mma...@mmarkk-work:/tmp$
>
> BUGGY CASE:
> mma...@mmarkk-work
On Thursday 13 Jan 2011 21:11:07 Joe Lightning wrote:
> Description:
> Bash doesn't like leading zeros in arithmetic expansion.
>
> Repeat-By:
> echo $(( 09 - 1 ))
It's all documented. Numbers with leading zeros are treated as octal. In your
case,
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
On Wednesday 19 Jan 2011 13:37:30 Greg Wooledge wrote:
> On Wed, Jan 19, 2011 at 10:49:47AM +0000, Davide Brini wrote:
> > In your second script, the "exit 0" part runs in a subshell, so "exit"
> > exits that subshell (and I'm somewhat surprised that no sem
On Sat, 5 Feb 2011 16:17:05 +0330
ali hagigat 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 -c 'exit 34') the
On Sun, 06 Feb 2011 15:01:24 +0800 jida...@jidanni.org wrote:
> Why add the four spaces?
> $ help read|perl -nwle 's/ $/ \$/ && print'
> $
> $
> $
> $
> $
> $
> $
> $
> $
>
And?
--
D.
On Thu, 17 Feb 2011 22:35:31 +0800
"Clark J. Wang" wrote:
> On Thu, Feb 17, 2011 at 9:20 PM, Andreas Schwab
> wrote:
>
> > "Clark J. Wang" writes:
> >
> > > See following script output:
> > >
> > > bash-4.2# cat quoted-pattern.sh
> > > [[ .a == \.a* ]] && echo 1 # not quoted
> > > [[ aa =~ \.a
On Thu, 17 Feb 2011 22:56:21 +0800
"Clark J. Wang" wrote:
> On Thu, Feb 17, 2011 at 7:09 PM, Clark J. Wang wrote:
>
> > See following script output:
> >
> > bash-4.2# cat quoted-pattern.sh
> > [[ .a == \.a* ]] && echo 1 # not quoted
> > [[ aa =~ \.a* ]] && echo 2 # quoted
> >
> > [[ aa =~ \a.
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
On Friday 25 Feb 2011 05:15:24 Eric Blake wrote:
> On 02/24/2011 03:14 PM, Michael Kalisz wrote:
> > $ echo $PWD/
> > will expand the $PWD variable to your current directory
> >
> > while in bash, version 4.2.0(1)-release:
> >
> > $ echo $PWD/
> > will just escape the $ in front of the $ variabl
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 ex
On Mon, 25 Jul 2011 14:28:52 -0700, Linda Walsh 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, b
On Mon, 08 Aug 2011 12:07:21 -0700, Linda Walsh 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() {
> # hit tab
On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini 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
depen
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' -DLOCALEDIR='/usr/share/local
On Thu, 07 Jun 2012 12:54:28 -0400, Chet Ramey 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
On Sat, 24 Nov 2012 21:08:16 +, "Alex Chupin (achupin)"
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 a
> n
On Mon, 26 Nov 2012 15:03:35 +0100, Davide Brini 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&q
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
On Tue, 19 Feb 2013 17:00:32 +1100, Nikolas Kallis
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 can also see
On Fri, 1 Mar 2013 15:27:31 +0200, Idan Kamara wrote:
> Hi,
>
> Is it possible to use the completion system to get a list of available
> options for a command bash knows how to auto-complete?
>
> Ideally, I'd like given the name of a program to get a list of pairs
> (option string, desc) for ea
On Thu, 30 May 2013 08:53:48 +0300, Pierre Gaston
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 to me th
On Thu, 30 May 2013 16:56:36 +0800, Chris Down 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 nullglob
> $ i=0
> $ w
On Thu, 30 May 2013 17:06:08 +0800, Chris Down wrote:
> That's... why I said he was unintentionally doing postincrement...
Doh! Indeed you said that. Apologies for reading too fast.
--
D.
On Thu, 2 Jan 2014 11:35:11 -0800, "P Fudd" 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
On Thu, 2 Jan 2014 11:35:11 -0800, "P Fudd" 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
> echo
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."
>
On Tue, 16 Sep 2014 21:02:54 +0200, Łukasz Wieczorek
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 visited this page:
> http:
On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey 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 earth that ar
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.
>
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 respecti
On Mon, 30 Aug 2010 18:35:46 +0800
"Clark J. Wang" wrote:
> The Bash manual says:
>
> "A double-quoted string preceded by a dollar sign ($) will cause the
> string to be translated according to the current locale. If the current
> locale is C or POSIX, the dollar sign is ignored. If the stri
On Mon, 30 Aug 2010 14:30:45 +0300 Pierre Gaston
wrote:
> On Mon, Aug 30, 2010 at 1:35 PM, Clark J. Wang wrote:
> > The Bash manual says:
> >
> > "A double-quoted string preceded by a dollar sign ($) will cause the
> > string to be translated according to the current locale. If the
> > current
On Fri, 15 Oct 2010 11:33:45 -0800 Ken Irving wrote:
> Note, though, that the '*' will still be there if the glob operation
> fails to expand to anything.
>
> $ echo foo /usrz*
> foo /usrz*
>
> I guess this makes sense, since just about all characters can be used in
> filenames, but I alwa
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 wh
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:
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 e
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 https://www.sta
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 lea
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 dan_home_bkp{
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 iss
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 e
On Sat, 14 Mar 2015 15:17:24 +0100, kont...@marcbihlmaier.de wrote:
> Description:
> exec hangs up when using "exec 2>SOMETHING". Just tested on
> Ubuntu 14.04, Ubuntu 12.04, Debian7
> working when just using "exec 1>SOMETHING"
>
> Repeat-By:
> using in a script for loggin
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 thin ice here.
--
D.
On Mon, 24 Jun 2024 10:50:15 -0600, Rob Gardner wrote:
[reformatted]
> $ readarray -d ' ' X <<< "A B C"
This does not remove the separator, so X[0] ends up containing "A ", X[1]
contains "B ", and X[2] contains "C\n" (as there was no trailing
space to terminate the string).
See:
$ declare -p X
On Mon, 24 Jun 2024 20:01:45 +0200, Davide Brini wrote:
> On Mon, 24 Jun 2024 10:50:15 -0600, Rob Gardner
> wrote:
>
> and a random 83 which is whatever follows in memory (strangely, it seems
> to be 83 consistently though).
Some more investigation shows that the "S" i
47 matches
Mail list logo
