Re: problem with continuation prompt on newlines with history back

On Sat, Jun 24, 2023, 02:23 Martin D Kealey wrote: > Hi Alex > hii Is your history set to line mode or command mode? This changes whether > recalling a multi-line history item gets put in the input buffer all at > once or only one line of it, and that in turn changes whether you see PS2 > in b

Re: problem with continuation prompt on newlines with history back

Hi Alex Is your history set to line mode or command mode? This changes whether recalling a multi-line history item gets put in the input buffer all at once or only one line of it, and that in turn changes whether you see PS2 in between the lines. On Sat, 24 Jun 2023, 03:34 alex xmb ratchev, wrot

problem with continuation prompt on newlines with history back

hi .. i was trying in termux PS1=' $PWD > ' /data/data/com.termux/files/home PS1=' $PWD > ' /data/data/com.termux/files/home --- 1. i entered with one newline np 2. i pressed up , 1. del ( make the ' away to continue ) and press enter .. the prompt continuation prompt is shown ,

Re: Possible problem with ${var%%[...]*}

On 4/2/23 1:28 PM, Robert Elz wrote: Date:Sun, 2 Apr 2023 17:48:24 +0200 From:Martin Schulte Message-ID: <20230402174824.01db4d51fd4f0061fdba7...@schrader-schulte.de> | in the following lines I consider dash's behaviour as correct | an bash's as wrong: All

Re: Possible problem with ${var%%[...]*}

On 4/2/23 12:54 PM, Oğuz wrote: 2 Nisan 2023 Pazar tarihinde Martin Schulte yazdı: Hello, in the following lines I consider dash's behaviour as correct an bash's as wrong: Bash expands `<()' as a process substitution. If you escape `<' or `(' it works fine. I am surprised that `<()' is no

Re: Possible problem with ${var%%[...]*}

On Mon, Apr 03, 2023 at 12:28:25AM +0700, Robert Elz wrote: > bash is parsing the <() as a process substitution, producing nothing. > The only chars in the bracket expression will then be . and [ which > explains the result. That does seem like a bug, to be fair. > Try instead > > bash

Re: Possible problem with ${var%%[...]*}

Date:Sun, 2 Apr 2023 17:48:24 +0200 From:Martin Schulte Message-ID: <20230402174824.01db4d51fd4f0061fdba7...@schrader-schulte.de> | in the following lines I consider dash's behaviour as correct | an bash's as wrong: All other shells (even ksh93) not just dash. I

Re: Possible problem with ${var%%[...]*}

2 Nisan 2023 Pazar tarihinde Martin Schulte yazdı: > Hello, > > in the following lines I consider dash's behaviour as correct an bash's as > wrong: > Bash expands `<()' as a process substitution. If you escape `<' or `(' it works fine. I am surprised that `<()' is not a syntax error when `()' i

Possible problem with ${var%%[...]*}

Hello, in the following lines I consider dash's behaviour as correct an bash's as wrong: $ uname -a Linux martnix4 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux $ bash--version | head -n 1 GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu) $ bash-5.2.15 --

Re: [PATCH] fix problem with uconvert

Dunno if it's "considerably easier", my patch just added 1 sign argument to 1 function and fixed up a couple of call sites. Your way is shorter but it boils down to "if the micro-part is negative it means that the number was in (-1,0)", which for some reason was already being checked for despite no

Re: [PATCH] fix problem with uconvert

On 10/22/22 2:58 PM, izabera wrote: if the argument is in the (-1, 0) range, the integer part is zero and multiplying it by -1 has no effect, so the caller can't tell that the argument was negative I suggest that a considerably easier way to solve this is *** ../bash-5.2-patched/lib/sh/uconver

[PATCH] fix problem with uconvert

if the argument is in the (-1, 0) range, the integer part is zero and multiplying it by -1 has no effect, so the caller can't tell that the argument was negative --- builtins/read.def | 10 +- examples/loadables/sleep.c | 4 ++-- externs.h | 2 +- lib/sh/uconver

Re: bash command completion has a problem with sudo command

On 8/22/22 2:10 AM, Hyunho Cho wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release ## when command completion function start running there are three variables automatically setting bash$ hello foo ba[tab] $1 (command):

bash command completion has a problem with sudo command

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 EliteBook 5.15.0-43-generic #46-Ubuntu SMP Tue Jul 12 10:30:17 UTC 2022 x86_64 x86_64

Re: Problem with sequences with variables?

On Wed, Apr 28, 2021 at 11:02:31PM +, Tom (AST) Watson via Bug reports for the GNU Bourne Again SHell wrote: > Hi... > > [user@box3 ~]$ echo $l > 10 > [user@box3 ~]$ echo {1..${l}} > {1..10} https://mywiki.wooledge.org/BashPitfalls#pf33

Re: Problem with sequences with variables?

On 4/28/21 7:02 PM, Tom (AST) Watson via Bug reports for the GNU Bourne Again SHell wrote: Hi... I was trying to do some sequences, and it looks like they don't like variables. See the following: Brace expansion happens first, before any of the other word expansions, so it requires integer c

Problem with sequences with variables?

Hi... I was trying to do some sequences, and it looks like they don't like variables. See the following: [user@box3 ~]$ echo $BASH_VERSION 5.0.17(1)-release [user@box3 ~]$ echo {1..10} 1 2 3 4 5 6 7 8 9 10 [user@box3 ~]$ echo $l 10 [user@box3 ~]$ echo {1..${l}} {1..10} [user@box3 ~]$ Shouldn't

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/5/20 9:13 AM, Detlef Vollmann wrote: > On 11/5/20 3:01 PM, Chet Ramey wrote: >> On 11/5/20 3:12 AM, Detlef Vollmann wrote: >>> On 11/4/20 9:06 PM, Detlef Vollmann wrote: What I don't understand yet is the highlighting. Sometimes (but rarely) I see the matched string highlighted

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/5/20 3:01 PM, Chet Ramey wrote: On 11/5/20 3:12 AM, Detlef Vollmann wrote: On 11/4/20 9:06 PM, Detlef Vollmann wrote: What I don't understand yet is the highlighting. Sometimes (but rarely) I see the matched string highlighted (actually only starting with the second character). But most o

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/5/20 3:12 AM, Detlef Vollmann wrote: > On 11/4/20 9:06 PM, Detlef Vollmann wrote: >> What I don't understand yet is the highlighting. >> Sometimes (but rarely) I see the matched string highlighted >> (actually only starting with the second character). >> But most of the time nothing is highli

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/5/20 9:39 AM, Lawrence Velázquez wrote: On Nov 5, 2020, at 3:12 AM, Detlef Vollmann wrote: BTW, I found no way to set a readline variable from the command line w/o an external file. $ echo "set enable-bracketed-paste On" | bind -f - didn't work. bind 'set enable-bracketed-paste On' Tha

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

> On Nov 5, 2020, at 3:12 AM, Detlef Vollmann wrote: > > BTW, I found no way to set a readline variable from the > command line w/o an external file. > $ echo "set enable-bracketed-paste On" | bind -f - > didn't work. bind 'set enable-bracketed-paste On' -- vq

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/4/20 9:06 PM, Detlef Vollmann wrote: What I don't understand yet is the highlighting. Sometimes (but rarely) I see the matched string highlighted (actually only starting with the second character). But most of the time nothing is highlighted while doing reverse-i-search. Sorry, it's as men

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/2/20 3:34 PM, Chet Ramey wrote: On 11/2/20 9:17 AM, Detlef Vollmann wrote: BTW, if you want me to check it you could send me a patch or push a commit to git.savannah.gnu.org/git/bash. It will be in the next devel branch push. Thanks. I tested it and it works nicely again :-) What I do

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/2/20 9:17 AM, Detlef Vollmann wrote: > BTW, if you want me to check it you could send me a patch or push > a commit to git.savannah.gnu.org/git/bash. It will be in the next devel branch push. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 11/1/20 8:58 PM, Chet Ramey wrote: On 10/31/20 11:00 AM, Detlef Vollmann wrote: Hello, since Bash-5.1-rc1 doesn't work for me as previously. I have the following entries in my history: man a man b Now I type ' m a n' and get: (reverse-i-search)`man': man b Now I type '' again. What I woul

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 10/31/20 11:00 AM, Detlef Vollmann wrote: > Hello, > > since Bash-5.1-rc1 doesn't work for me as previously. > I have the following entries in my history: > man a > man b > > Now I type ' m a n' and get: > (reverse-i-search)`man': man b > > Now I type '' again. > What I would expect (and wha

Re: Problem with reverse-i-search in 5.1.0(1)-rc1

On 10/31/20 4:00 PM, Detlef Vollmann wrote: Hello, since Bash-5.1-rc1 doesn't work for me as previously. I have the following entries in my history: man a man b Now I type ' m a n' and get: (reverse-i-search)`man': man b Now I type '' again. What I would expect (and what I got with 5.0) is: (

Problem with reverse-i-search in 5.1.0(1)-rc1

Hello, since Bash-5.1-rc1 doesn't work for me as previously. I have the following entries in my history: man a man b Now I type ' m a n' and get: (reverse-i-search)`man': man b Now I type '' again. What I would expect (and what I got with 5.0) is: (reverse-i-search)`man': man a Instead I get

Re: problem with using ctrl-x ctrl-e ( open vi editor )

On 10/18/20 10:34 PM, Hyunho Cho wrote: > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > # > > bash$ cat <<\EOF # without using ctrl-x ctrl-e there is no problem > occurred. >> 111 >> 222 >> EOF > 111 > 222 > >

problem with using ctrl-x ctrl-e ( open vi editor )

Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux EliteBook 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:2

Re: problem with extra space; setting? cygwin only?

ders (otherwise they simply won't bother reading). | or lists where attachments are not allowed. Yes, that is a problem - with those the best can be to make the content you want to be seen available somewhere, and in the e-mail include a URL for that, That is not nearly as good - many people

Re: problem with extra space; setting? cygwin only?

On Thu, Jun 25, 2020 at 10:46:01AM -0700, L A Walsh wrote: > But that wouldn't follow the email response instructions of posting your > response above the previous email STOP DOING THAT! That's the OPPOSITE of what you're supposed to do on Unix-based mailing lists, Usenet, and other sensible plac

Re: problem with extra space; setting? cygwin only?

But that wouldn't follow the email response instructions of posting your response above the previous email or lists where attachments are not allowed. It also requires putting the 'to-be-protected-text' in a separate file, on the same computer** or on the local computer (depending on which email s

Re: problem with extra space; setting? cygwin only?

If you have code to send and formatting is important, put it in a file and attach it to the messages. Almost all mail systems transmit attached files without damaging them. Dale

Re: problem with extra space; setting? cygwin only?

re: IFS... yup. that was it, not sure how it got cleared, but it did. Thanks for the clue. As for gmailnecessity creates unfortunate circumstances...having your main file system (RAID 0) fail, along with your backups (in a separate disk enclosure, also RAID 0), isn't something that happens ev

Re: problem with extra space; setting? cygwin only?

On 6/23/20 3:21 PM, L A Walsh wrote: > I do: > > set output > echo ">$1<" >> output< > output=""printf ${1:+-v $1} "%s:%s" 23 myproc > > > > -Bash: printf: ` output': not a valid identifier It looks like word splitting on the result of ${1:+-v $1} isn't taking place. That might be due to IFS;

Re: problem with extra space; setting? cygwin only?

On 6/23/20 3:33 PM, L A Walsh wrote: > On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote: > >> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote: >>> set output >>> output=""printf ${1:+-v $1} "%s:%s" 23 myproc >>> -Bash: printf: ` output': not a valid identifier >> >> Your command is

Re: problem with extra space; setting? cygwin only?

On Tue, Jun 23, 2020 at 12:33:23PM -0700, L A Walsh wrote: > It's a gmail feature to mangle your input in weird ways when you cut/paste. > the line with 'output=""' is separate from the "printf" line. Sorry. First, stop top-quoting. Second, if you know that gmail is horrible and is going to mang

Re: problem with extra space; setting? cygwin only?

It's a gmail feature to mangle your input in weird ways when you cut/paste. the line with 'output=""' is separate from the "printf" line. Sorry. On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote: > On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote: > > set output > > output=""print

Re: problem with extra space; setting? cygwin only?

there was a linefeed in my source between output="" and the printf. It's a gmail feature to mangle your input. On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote: > On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote: > > set output > > output=""printf ${1:+-v $1} "%s:%s" 23 myproc > >

Re: problem with extra space; setting? cygwin only?

On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote: > set output > output=""printf ${1:+-v $1} "%s:%s" 23 myproc > -Bash: printf: ` output': not a valid identifier Your command is simply wrong. You've got two double-quotes in a row, which simply cancel each other out, as they contain only

problem with extra space; setting? cygwin only?

I do: set output echo ">$1<" >output< output=""printf ${1:+-v $1} "%s:%s" 23 myproc -Bash: printf: ` output': not a valid identifier for some reason it is regarding the space before $1 in the printf as part of the variable name. It doesn't seem to do this on linux (lnx 4.4.12(3), cyg-4.4.12

Re: bash-5.0: problem with variable scoping in posix-mode

> > Description: > > > > There is a problem with variable scoping when variable is created from > > assignment statement preceding function call in posix-mode. See an > > example below. > > > > > > Repeat-By: > > > > $ cat

Re: small problem with install on POSIX type Solaris due to O_CLOEXEC used in examples fdflags.c

On 2/6/19 7:02 PM, Dennis Clarke wrote: > > Just a minor nit. > > The examples file fdflags.c uses flag O_CLOEXEC which of course does not > exist on Solaris or any linux previous to 2.6.23 so of course install > blows up a bit.  Trivial hack solution is I remove fdflags from the > examples insta

small problem with install on POSIX type Solaris due to O_CLOEXEC used in examples fdflags.c

Just a minor nit. The examples file fdflags.c uses flag O_CLOEXEC which of course does not exist on Solaris or any linux previous to 2.6.23 so of course install blows up a bit. Trivial hack solution is I remove fdflags from the examples install phase and life goes on neatly. Sure we have : /

Re: bash-5.0: problem with variable scoping in posix-mode

On 1/28/19 6:24 PM, Martijn Dekker wrote: > Op 27-01-19 om 22:59 schreef Chet Ramey: >> This is a consequence of a combination of two POSIX features. First, POSIX >> requires assignment statements preceding special builtins to create global >> variables (POSIX has no local variables) that persist i

Re: bash-5.0: problem with variable scoping in posix-mode

Op 27-01-19 om 22:59 schreef Chet Ramey: > This is a consequence of a combination of two POSIX features. First, POSIX > requires assignment statements preceding special builtins to create global > variables (POSIX has no local variables) that persist in the shell context > after the special builtin

Re: bash-5.0: problem with variable scoping in posix-mode

On 1/27/19 7:58 AM, Alexander Tsoy wrote: > Bash Version: 5.0 > Patch Level: 2 > Release Status: release > > > Description: > > There is a problem with variable scoping when variable is created from > assignment statement preceding function call in posix-m

bash-5.0: problem with variable scoping in posix-mode

/L56xx/X56xx (IBRS update) GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 2 Release Status: release Description: There is a problem with variable scoping when variable is created from assignment statement preceding function call in posix-mode. See an example

Re: problem with bash script loading

On Sat, Jan 05, 2019 at 08:28:45AM +, Paulo Nogueira wrote: > What occurred to me is the following: suppose a script s1 starts > being executed, by forking say, and then s1 is overwritten DON'T... DO... THAT. Problem solved.

Re: problem with bash script loading

On 1/5/19 3:28 AM, Paulo Nogueira wrote: >  What occurred to me is the following: suppose a script s1 starts >  being executed, by forking say, and then s1 is overwritten; bash >  detects this and re-reads the file. Bash doesn't do that. > OK, then exactly where does >  bash continue executing

Re: problem with bash script loading

On Sat, 29 Dec 2018, Chet Ramey wrote: http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00023.html Not sure if I understood everything, so allow me to quote you, from http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00024.html ... It's been there even since I wrote the buf

Re: problem with bash script loading

On 12/29/18 6:09 AM, Paulo Nogueira wrote: > > > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > >  I've come to the conclusion that bash scripts > >  (1) are not entirely loaded in memory at once > >  or, at least, > >  (2) are re-read (from the disk?) if th

problem with bash script loading

Bash Version: 4.4 Patch Level: 19 Release Status: release Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Description: I've come to the conclusion that bash scripts (1) are not entirely loaded in memory at once or, at least, (2) are re-read (from the disk?) i

Re: Problem with vi mode in bash 5.0 beta

On 12/12/18 5:32 PM, Stan Marsh wrote: > (This is all after doing "set -o vi") > > In previous versions of bash, I could do the following keys: / ^ foo > > and it would find the most recent command that starts with foo. This is all > as > expected. > > However, in bash 5.0 beta (self-compile

Problem with vi mode in bash 5.0 beta

(This is all after doing "set -o vi") In previous versions of bash, I could do the following keys: / ^ foo and it would find the most recent command that starts with foo. This is all as expected. However, in bash 5.0 beta (self-compiled), this doesn't work. It always leaves the cursor line e

Re: Problem with list of aliases

On 3/14/17 12:56 PM, Pedro Gimeno wrote: > When using the 'alias' command without parameters, or with the '-p' > parameter, a list of aliases is displayed. This list has the form: > > alias name='value' > > 'help alias' states that this form is 'reusable', thus implying, if I > understand it

Problem with list of aliases

When using the 'alias' command without parameters, or with the '-p' parameter, a list of aliases is displayed. This list has the form: alias name='value' 'help alias' states that this form is 'reusable', thus implying, if I understand it correctly, that it can be fed back to bash. But that's

Re: Problem with 'upper' class when nocaseglob

On 3/2/17 4:57 PM, Lukáš Bařinka wrote: > A description of the bug behaviour: >When the nocaseglob option is set, the [:upper:] class in pattern >does not match capital or small letters. On the other hand, >[:lower:] works fine. Thanks for the report. Character class name matching sho

Re: Problem with 'upper' class when nocaseglob

On Thu, Mar 02, 2017 at 10:57:57PM +0100, Luká?? Ba??inka wrote: > A short script or ???recipe??? which exercises the bug and may be used > to reproduce it: >$ touch a A >$ echo [[:upper:]] >A >$ shopt -s nocaseglob >$ echo [[:lower:]] >a A >$ echo [[:upper:]] >[[:up

Problem with 'upper' class when nocaseglob

The version number of Bash: GNU bash, version 4.4.11(1)-release The hardware and operating system: x86_64-pc-linux-gnu, Debian GNU/Linux 9 A description of the bug behaviour: When the nocaseglob option is set, the [:upper:] class in pattern does not match capital or small letters. On

Re: problem with redir test

> > during testing of latest bash on Solaris I found strange behavior. We > > run the tests with clear environment (env -). It seems to be caused by > > undefined SHELL variable. The test reported > > > > 150,151c150,151 > > < ./redir11.sub: line 26: echo: write error: Bad file number > > < ./redi

Re: problem with redir test

On 12/1/16 2:35 PM, Vladimir Marek wrote: > Hi, > > during testing of latest bash on Solaris I found strange behavior. We > run the tests with clear environment (env -). It seems to be caused by > undefined SHELL variable. The test reported > > 150,151c150,151 > < ./redir11.sub: line 26: echo: wr

problem with redir test

Hi, during testing of latest bash on Solaris I found strange behavior. We run the tests with clear environment (env -). It seems to be caused by undefined SHELL variable. The test reported 150,151c150,151 < ./redir11.sub: line 26: echo: write error: Bad file number < ./redir11.sub: line 27: echo:

Re: Problem with small script

> On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > The script: > > #/bin/bash ^ missing ! here typo in the shebang? > > # testlink.sh > > # must be run as root > > > > file1="$1" > > shift > > mandir=/usr/local/share/man/man3/ > > cp "$file1" "$mandir" > > cd "$mandir" >

Re: Problem with small script

On Fri, Feb 19, 2016 at 12:45 AM, Greg Wooledge wrote: > On Thu, Feb 18, 2016 at 05:58:28PM +0100, baldu...@units.it wrote: > > > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > > > The script: > > > > #/bin/bash > > ^ missing ! here > > > > typo in the shebang? > > Yes, n

Re: Problem with small script

On Thu, Feb 18, 2016 at 05:58:28PM +0100, baldu...@units.it wrote: > > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > > The script: > > > #/bin/bash > ^ missing ! here > > typo in the shebang? Yes, nicely done. I missed that. On Fri, Feb 19, 2016 at 12:22:20AM +0700, R

Re: Problem with small script

On Thu, Feb 18, 2016 at 11:30 PM, Greg Wooledge wrote: > On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > > The script: > > #/bin/bash > > # testlink.sh > > # must be run as root > > > > file1="$1" > > shift > > mandir=/usr/local/share/man/man3/ > > cp "$file1" "$mandir" > > cd "$

Re: Problem with small script

On Thu, Feb 18, 2016 at 11:06:37PM +0700, Robert Parker wrote: > The script: > #/bin/bash > # testlink.sh > # must be run as root > > file1="$1" > shift > mandir=/usr/local/share/man/man3/ > cp "$file1" "$mandir" > cd "$mandir" You MUST check the result of cd. If it fails but you continue on, yo

Problem with small script

The script: #/bin/bash # testlink.sh # must be run as root file1="$1" shift mandir=/usr/local/share/man/man3/ cp "$file1" "$mandir" cd "$mandir" echo '$hash = '"$#" while (( "$#" )); do file2="$1" ln "$file1" "$file2" shift done Results: >> sudo ./testlink.sh readfile.3 readtextfile.3

Re: Strange Problem with 'test' or '['

On Wed, Dec 23, 2015 at 04:05:28PM +0100, Bytec GmbH - Helmut Koeberle wrote: > OK, with '[[' ist's working! > > if ([[ "true" = "true" ]] && [[ "${h:0:1}" = "/" ]]); then echo slash; fi You don't need parentheses around it. The parentheses force the commands to run in a subshell (fork()), so it

Re: Strange Problem with 'test' or '['

On 12/23/15 5:26 AM, Bytec GmbH - Helmut Koeberle wrote: > Hello list, > > i have a strange problem in bash with the test command. > > Here is my simple bash script 'tst' that checks wether the first char of > an argument is a slash. > If the first char of the argument is a special char like '('

Re: Strange Problem with 'test' or '['

On Wed, Dec 23, 2015 at 11:26:51AM +0100, Bytec GmbH - Helmut Koeberle wrote: > Here is my simple bash script 'tst' that checks wether the first char of > an argument is a slash. It can be written in a much simpler way: [[ $arg = /* ]] Or: case $arg in /*) ... This part actually does look like

Strange Problem with 'test' or '['

Hello list, i have a strange problem in bash with the test command. Here is my simple bash script 'tst' that checks wether the first char of an argument is a slash. If the first char of the argument is a special char like '(' then it works if there is one expression, but not with multiple express

Re: Comparison problem with case modification expansion in bash-4.3

On 11/3/15 9:03 AM, Corentin Peuvrel wrote: > Hi, > > I think I found a bug in bash-4.3 (4.3.42 in fedora 21), that seems to exists > for a long time (at least from 4.1.2 in Centos 6). > > I found a fairly simple way to reproduce it : you have to initialize a > variable to an empty string, and

Comparison problem with case modification expansion in bash-4.3

Hi, I think I found a bug in bash-4.3 (4.3.42 in fedora 21), that seems to exists for a long time (at least from 4.1.2 in Centos 6). I found a fairly simple way to reproduce it : you have to initialize a variable to an empty string, and do a comparaison to it while doing the case modification

Re: problem with @A and arrays

On 10/18/15, Chet Ramey wrote: > (BTW, your patch does not result in a valid declare command with a > correct compound assignment.) > Yes I'm sorry, I noticed it after sending the message... --- xoxo iza

Re: problem with @A and arrays

On 10/16/15 8:55 PM, isabella parakiss wrote: > ${array[@]@A} splits the values. > > $ a=("ab" "c d"); printf "<%s>" "${a[@]@A}" > <-a><[1]="c> Thanks for the report. This will be fixed in the next bash release. (BTW, your patch does not result in a valid declare command with a correct com

problem with @A and arrays

${array[@]@A} splits the values. $ a=("ab" "c d"); printf "<%s>" "${a[@]@A}" <-a><[1]="c> diff --git a/subst.c b/subst.c index 2a7366f..d7258b8 100644 --- a/subst.c +++ b/subst.c @@ -4796,18 +4796,26 @@ array_var_assignment (v, itype, quoted) { char *ret, *val, flags[MAX_ATTRIBUTES];

Re: Problem with @Q

On 8/29/15 2:40 AM, isabella parakiss wrote: > In the devel branch, setting IFS=\' seems to break @Q: It actually causes a lot more than that to misbehave, and has for a very long time. It looks like "'" is an uncommon IFS value. This will be fixed for the next bash-4.4 testing release. -- ``T

Problem with @Q

In the devel branch, setting IFS=\' seems to break @Q: $ arr=(a b c) $ echo ${arr[@]@Q} | sed -n l 'a' 'b' 'c'$ <- correct $ echo "${arr[@]@Q}" | sed -n l 'a' 'b' 'c'$ <- correct $ IFS=\' $ echo ${arr[@]@Q} | sed -n l a b c$

problem with {Z..a} and backticks

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' -DPACKA

Re: problem with HISTCONTROL

On 7/11/15 12:43 PM, isabella parakiss wrote: > When the value of HISTCONTROL is ignoredups or ignoreboth, if you enter > a command and then open the editor and add lines to it without changing > the first line, only the first line will be stored in the history. > > I'm terrible at explaining, but

Re: problem with local -

On 7/10/15 12:52 PM, isabella parakiss wrote: > Using local - calls set_ignoreeof() when unwinding "function_calling". > As a result, you have to press ^D 10 times to exit the shell. > Anyway, $IGNOREEOF is not changed and shopt -o ignoreeof reports off. I can't reproduce this. When I test it, wi

problem with HISTCONTROL

When the value of HISTCONTROL is ignoredups or ignoreboth, if you enter a command and then open the editor and add lines to it without changing the first line, only the first line will be stored in the history. I'm terrible at explaining, but I recorded what happens: https://asciinema.org/a/23275

problem with local -

Using local - calls set_ignoreeof() when unwinding "function_calling". As a result, you have to press ^D 10 times to exit the shell. Anyway, $IGNOREEOF is not changed and shopt -o ignoreeof reports off. I'm attaching the relevant part of a backtrace from gdb. --- xoxo iza gdb-trace Description

Re: Problem with bind -x

On 4/21/15 3:42 PM, isabella parakiss wrote: > I noticed a problem with bind -x: readline re-prints the line if the > function is called when the cursor is not in the first line. This is a difficult problem. The readline redisplay engine does not know where the cursor is when the c

Re: Problem with brace expansion

On Thu, Apr 23, 2015 at 01:01:43AM +0100, Dr Alun J. Carr wrote: > Well, to be strictly conformant with heirloom SysV sh, Nobody cares about compatibility with Bourne shell any more. Not since Solaris finally pulled its head out of its ass and put a POSIX sh in /bin (20 years after everyone else)

Re: Problem with brace expansion

Well, to be strictly conformant with heirloom SysV sh, we have to use the following (which is uglier than Cobol with a hangover): #looper2-sh.sh n=4 i=1 while [ $i -le $n ] do echo i = $i i=`expr $i + 1` done which also works with dash and mksh. Perhaps this needs to go into a FAQ somew

Re: Problem with brace expansion

On 04/21/2015 01:44 PM, Dr Alun J. Carr wrote: > Tests were done with bash, ksh, zsh, pdksh, dash and heirloom System V Bourne > sh with the following versions: > bash 3.2.57(1) > bash 4.3.33(1) > ksh version sh (AT&T Research) 93u+ 2012-08-01 > zsh 5.0.5 (x86_64-app

Re: Problem with brace expansion

On Tue, Apr 21, 2015 at 2:44 PM, Dr Alun J. Carr wrote: > There appears to be a bug in bash when using a variable in curly brace > expansion, e.g., {1..$n}. I have put the two following test scripts in the > attached files looper1.sh and looper2.sh: > > #looper1.sh > for i in {1..4} > do > ec

Re: Problem with brace expansion

On Tue, 21 Apr 2015, Dr Alun J. Carr wrote: There appears to be a bug in bash when using a variable in curly brace expansion, e.g., {1..$n}. I have put the two following test scripts in the attached files looper1.sh and looper2.sh: Brace expansion is done before variable expansion: T

Problem with brace expansion

There appears to be a bug in bash when using a variable in curly brace expansion, e.g., {1..$n}. I have put the two following test scripts in the attached files looper1.sh and looper2.sh: #looper1.sh for i in {1..4} do echo i = $i done #looper2.sh n=4 for i in {1..$n} do echo i = $i don

Problem with bind -x

I noticed a problem with bind -x: readline re-prints the line if the function is called when the cursor is not in the first line. To reproduce it (and to understand what I mean, if it's not clear): prompt$ myfunc () { :; } prompt$ bind -x '"\C-a":myfunc' Now write a l

Re: [Bug-readline] Problem with CTRL-z and readline()

On 3/2/15 9:29 AM, Dave Wysochanski wrote: > I agree this is what is happening - the signal handler loops around > pathologically trying the same operation and getting the same result. > Can you explain why the problem is intermittent? I can reproduce it but > not always. It's a race condition:

Re: [Bug-readline] Problem with CTRL-z and readline()

On Sun, 2015-03-01 at 20:14 -0500, Chet Ramey wrote: > On 2/27/15 12:10 PM, Dave Anderson wrote: > > > > This issue was first reported with respect to the crash utility, > > which is an interactive program that uses the readline library. > > > > The problem occurs only if the crash utility is r

Re: [Bug-readline] Problem with CTRL-z and readline()

2015-03-02 2:14 GMT+01:00 Chet Ramey : > Any ideas are welcome. > I have never thought very deeply about this, but rlwrap (which uses the alternate interface and has its own signal handlers) remains suspended in the SIGTSTP signal handler (by resetting the SIGTSTP disposition and then sending a S

Re: [Bug-readline] Problem with CTRL-z and readline()

2015-03-02 10:47 GMT+01:00 Hans Lub : > and defers the restoring until after wakeup (cf signals.c > ). > Now I realize that rlwrap doesn't restore terminal attributes after a SIGTSTP, and will leave them modified when killed by a

Re: [Bug-readline] Problem with CTRL-z and readline()

On 2/27/15 12:10 PM, Dave Anderson wrote: > > This issue was first reported with respect to the crash utility, > which is an interactive program that uses the readline library. > > The problem occurs only if the crash utility is run from within > an executable bash script, i.e., like so: > >

  1   2   3   >