Re: Error in "help ulimit": missing unit info

On 7/14/24 9:59 AM, Carlo Teubner wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: "help ulimit" includes this paragraph: Thanks for the report. This was changed in the devel branch some time ago. -- ``The lyf so short, the craft so long to lerne.'' - Cha

Re: Error with SIGCHLD trap and process substitution

On 2/2/24 3:32 PM, Tavian Barnes wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When a SIGCHLD trap is set, commands that include two process substitutions fail with a strange "unexpected EOF" error. Thanks for the report. This was fixed last September, the re

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: error message lacks useful debugging information

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 > from: https://github.com/Denvi/Candle > Extract to the fold

Re: error message lacks useful debugging information

On 10/5/23 2:09 PM, Dave Cigna via Bug reports for the GNU Bourne Again SHell wrote: I want to thank all of you for taking this issue seriously. I'm sure you all agree that when something fails, the error message should provide useful information about what went wrong. An error message should

Re: error message lacks useful debugging information

I want to thank all of you for taking this issue seriously. I'm sure you all agree that when something fails, the error message should provide useful information about what went wrong. If bash simply doesn't have the information because the kernel didn't provide it, then perhaps I should throw

Re: error message lacks useful debugging information

On Thu, Oct 5, 2023 at 12:57 PM Greg Wooledge wrote: > On Thu, Oct 05, 2023 at 07:04:26AM +0200, Phi Debian wrote: > > Since we are on the error path (not the perf path) may be the shell could > > go the extra miles and try some more diag, has it does for shebang, on > > ENOENT, the shell could t

Re: error message lacks useful debugging information

On Thu, Oct 05, 2023 at 07:04:26AM +0200, Phi Debian wrote: > Since we are on the error path (not the perf path) may be the shell could > go the extra miles and try some more diag, has it does for shebang, on > ENOENT, the shell could try to open the a.out, if OK try some other > euristics, [...]

Re: error message lacks useful debugging information

Since we are on the error path (not the perf path) may be the shell could go the extra miles and try some more diag, has it does for shebang, on ENOENT, the shell could try to open the a.out, if OK try some other euristics, at least the trivial one i.e the multilib case that seems the most disorien

Re: error message lacks useful debugging information

On Wed, 4 Oct 2023 20:05:41 -0400 Dave Cigna via Bug reports for the GNU Bourne Again SHell wrote: > Description: > > Attempting to tun an executable file (not a bash script) with the following > command: > > ./Candle > > the following error message is reported by bash: > > bash: ./Candle: c

Re: error message lacks useful debugging information

On Wed, Oct 04, 2023 at 08:05:41PM -0400, Dave Cigna via Bug reports for the GNU Bourne Again SHell wrote: > Attempting to tun an executable file (not a bash script) with the following > command: > > ./Candle > > the following error message is reported by bash: > > bash: ./Candle: cannot execut

Re: !& error

On 8/20/23 6:49 PM, Grisha Levit wrote: Sorry if it was premature. Btw I'm not sure about the fix for this in https://git.savannah.gnu.org/cgit/bash.git/diff/execute_cmd.c?h=devel&id=b64a7d8c Running `! &' stil

Re: !& error

On Mon, Aug 14, 2023, 15:29 Chet Ramey wrote: > On 8/12/23 1:56 PM, Grisha Levit wrote: > > The newly added support for `! &' uses the previous value of > > the_printed_command_except_trap or segfaults if none has been made yet: > > Thanks for the report. You're Johnny on the spot here -- I hadn'

Re: !& error

On 8/12/23 1:56 PM, Grisha Levit wrote: The newly added support for `! &' uses the previous value of the_printed_command_except_trap or segfaults if none has been made yet: Thanks for the report. You're Johnny on the spot here -- I hadn't started writing tests for this yet. Chet -- ``The lyf

Re: Error message: cannot find _struct in shared object

On 5/27/23 12:39 PM, Wiley Young wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: A syntax error on a variable assignment lead to $x being unset when `enable -n "$x" was executed, which produced this error message: ./test.sh: line 22: enable: cannot find _struct

Re: Error message: cannot find _struct in shared object

On Sat, May 27, 2023 at 09:39:18AM -0700, Wiley Young wrote: > Description: > > A syntax error on a variable assignment lead to $x being unset when `enable > -n "$x" was executed, which produced this error message: > ./test.sh: line 22: enable: cannot find _struct in shared object : > /usr/bin/b

Re: Error report - 3.5.3 Shell Parameter Expansion

greets .. On Sun, 23 Apr 2023, 10:23 pm Rob Liversage, wrote: > Apologies. Please ignore. I realized I was a bit hasty. > > On Sun, Apr 23, 2023 at 8:18 PM Rob Liversage > wrote: > > > Hello > > > > At: > > > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Shell-Parameter-Expan

Re: Error report - 3.5.3 Shell Parameter Expansion

Apologies. Please ignore. I realized I was a bit hasty. On Sun, Apr 23, 2023 at 8:18 PM Rob Liversage wrote: > Hello > > At: > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Shell-Parameter-Expansion > 3.5.3 Shell Parameter Expansion > The example: > > $ v=123 > $ echo ${v-unse

Re: error messages for [[ don't include "[[: " when a DEBUG trap is present

On 6/15/22 1:52 PM, Emanuele Torre wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When a DEBUG traps is present, error messages for `((' and `[[' commands don't contain "((: " or "[[: ". Thanks for the report. I'll fix this for the next devel bra

Re: error in hours given by date -d @anyNumber

On Mon, Jan 17, 2022 at 09:10:59PM +0100, Girod Valentin wrote: > Description: > when using date -d @customNumber +%H, > it returns 1 more hour that the expected hour. First thing to note: date(1) is not part of bash. It's part of GNU coreutils, if you're on a GNU/Linux system. You're re

Re: error in hours given by date -d @anyNumber

On 1/17/22 3:10 PM, Girod Valentin wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description:     when using date -d @customNumber +%H,     it returns 1 more hour that the expected hour. Repeat-By:     date -d @0 +%T     returns: 01:00:00 (WHAT THE FUCK) This is not a b

Re: Error in bash documentation for builtin declare

On 11/6/20 12:21 PM, Edouard Thiel wrote: >>> By the way, I have seen that the nameref works more or less for functions: >>> $ foo() { echo "hello" ;} >>> $ declare -n bar=foo >>> but the reference has to be dereferenced when calling: >>> $ ${!bar} >>> hello >>> >>> is it still the case in bash 5?

Re: Error in bash documentation for builtin declare

Le 06/11/2020 à 18:06, Chet Ramey a écrit : On 11/6/20 11:53 AM, Edouard Thiel wrote: This is more clear, and in fact, ok for me (if subscripted means associative?); the link above is not up to date. The same language appears in the "Shell Parameters" section of the manual at the above link

Re: Error in bash documentation for builtin declare

On 11/6/20 11:53 AM, Edouard Thiel wrote: > > > Le 06/11/2020 à 17:01, Greg Wooledge a écrit : >> On Fri, Nov 06, 2020 at 02:07:36PM +0100, Edouard Thiel wrote: >>> there is an error in the bash documentation: >>> https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins >>> >>> In th

Re: Error in bash documentation for builtin declare

Le 06/11/2020 à 17:01, Greg Wooledge a écrit : On Fri, Nov 06, 2020 at 02:07:36PM +0100, Edouard Thiel wrote: there is an error in the bash documentation:     https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins In the 'declare' builtin, option '-n',  last sentence:     "The na

Re: Error in bash documentation for builtin declare

On 11/6/20 8:07 AM, Edouard Thiel wrote: > Hello, > > there is an error in the bash documentation: >     https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins > > In the 'declare' builtin, option '-n',  last sentence: >     "The nameref attribute cannot be applied to array variables" >

Re: Error in bash documentation for builtin declare

On Fri, Nov 06, 2020 at 02:07:36PM +0100, Edouard Thiel wrote: > there is an error in the bash documentation: >     https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins > > In the 'declare' builtin, option '-n',  last sentence: >     "The nameref attribute cannot be applied to array va

Re: Error expanding variable containing a directory name

> On Jul 23, 2020, at 12:08 PM, Lutz Adam wrote: > > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: >The content of $ML is "/media/lad". There's a directory >/media/lad/p24. Typing the command > ls $ML/p24 >a backslash is put b

Re: Error expanding variable containing a directory name

On 7/23/20 12:08 PM, Lutz Adam wrote: > Description: >    The content of $ML is "/media/lad".  There's a directory > /media/lad/p24. Typing the command >             ls $ML/p24 >    a backslash is put befor "$" and the line looks like: >             ls \$ML/p24/ >    Typing the ENTER ke

Re: Error in the manual regarding the '=~' operator

On 4/9/20 7:19 AM, Guebitz Roland wrote: > Hello, > in the section > https://www.gnu.org/software/bash/manual/bash.html#Conditional-Constructs > you have this example: > [[ $line =~ [[:space:]]*?(a)b ]] > The expression ?() is not part of the Posix ERE. It is part of bash pattern > matching: https

Re: Error on arithmetic evaluation of `~0`.

On 12/28/18 11:26 PM, Bize Ma wrote: > Chet Ramey (mailto:chet.ra...@case.edu>>) wrote: > > On 12/23/18 12:01 PM, Bize Ma wrote: > > {…} > > > Both command line above should have printed "hello". > > No. 0 is the only valid subscript for a non-array variable. The difference > be

Re: Error on arithmetic evaluation of `~0`.

On Sat, Dec 29, 2018, 1:44 PM Bize Ma Chet Ramey () wrote: > > > On 12/23/18 12:01 PM, Bize Ma wrote: > > > {…} > > > > Both command line above should have printed "hello". > > > > No. 0 is the only valid subscript for a non-array variable. The > difference > > between bash and other shells that i

Re: Error on arithmetic evaluation of `~0`.

Chet Ramey () wrote: > On 12/23/18 12:01 PM, Bize Ma wrote: > {…} > > Both command line above should have printed "hello". > > No. 0 is the only valid subscript for a non-array variable. The difference > between bash and other shells that implement this feature is that bash > warns about negative

Re: Error on arithmetic evaluation of `~0`.

Simple variables convert to array variables dynamically, but that doesn't mean they should be interpreted exactly as if they are. I see that more of just a convenient feature. On Mon, Dec 24, 2018, 1:02 AM Bize Ma Chet Ramey () wrote: > > > > > > > While this works: > > > > > > var=(hello); echo

Re: Error on arithmetic evaluation of `~0`.

On 12/23/18 12:01 PM, Bize Ma wrote: > Chet Ramey (mailto:chet.ra...@case.edu>>) wrote: > > > > > While this works: > > > > var=(hello); echo "${var[ ~0]}" > > hello > > Because negative array subscripts count backwards from the end of the > array. > > > Doh!, yes. A

Re: Error on arithmetic evaluation of `~0`.

Chet Ramey () wrote: > > > > While this works: > > > > var=(hello); echo "${var[ ~0]}" > > hello > > Because negative array subscripts count backwards from the end of the > array. > Doh!, yes. And, because of that: "${var[-1]}" should give the *last* element of array "var", shouldn't it? Consequ

Re: Error on arithmetic evaluation of `~0`.

On 12/20/18 8:12 AM, Greg Wooledge wrote: > The issue you're reporting appears to be present in arithmetic contexts > in general, not only arrays: > > wooledg:~$ echo $((~0)) > bash: /home/wooledg: syntax error: operand expected (error token is > "/home/wooledg") This is what was fixed post-bas

Re: Error on arithmetic evaluation of `~0`.

On 12/19/18 10:31 PM, Bize Ma wrote: > This is the third time I am reporting this issue. Not really, but let's go on. > > This fails: > > var=(hello); echo "${var[~0]}" > syntax error: operand expected ... Yes. The comment in the code says: "Right now, the code suppresses tilde expansion whe

Re: Error on arithmetic evaluation of `~0`.

On Dez 20 2018, Greg Wooledge wrote: > The issue you're reporting appears to be present in arithmetic contexts > in general, not only arrays: > > wooledg:~$ echo $((~0)) > bash: /home/wooledg: syntax error: operand expected (error token is > "/home/wooledg") This has been fixed in bash 5.0. >

Re: Error on arithmetic evaluation of `~0`.

On Wed, Dec 19, 2018 at 10:31:36PM -0500, Bize Ma wrote: > It is also interesting that this fails: > > var=hello; echo "${var[ ~0]}" > bash: var: bad array subscript > > Isn't `var[0]` valid and equivalent to `var` ? Yes, but ~0 is not 0. wooledg:~$ echo $(( ~0)) -1 The issue you're reporting

Re: error message for missing fi is not helpful

On 9/13/2018 1:21 PM, Chet Ramey wrote: I'm sure you noticed that word_lineno isn't set for every compound command and that it's limited. Actually I didn't notice. Under what circumstances is it not set? What is it's purpose if it's not to keep track of a stack of nested conditio

Re: error message for missing fi is not helpful

On 13.09.2018 04:29, L A Walsh wrote: This isn't *exactly* what you wanted, but this gives the line number of the last unmatched statement (but doesn't tell you what the statement was).  The diff was against bash-4.4.23 (4.4 base w/23 patches) Thank you for taking the time to look into this! Th

Re: error message for missing fi is not helpful

On 9/12/18 10:29 PM, L A Walsh wrote: > I can't speak for formatting or base-specific function usage, but I don't > think there was any of those. > > Anyway, if you store the word in a separate array where the line # > is stored, you _could_ list the matching word, but I suspect just the > line i

Re: error message for missing fi is not helpful

On 9/12/2018 6:35 AM, Chet Ramey wrote: On 9/12/18 5:17 AM, Manuel Reiter wrote: Bash Version: 4.4 Patch Level: 12 Release Status: release ++ Description: When an if statement is not terminated by a fi, bash's error message is not helpful in locating the problem. This is tough to

Re: error message for missing fi is not helpful

On 9/12/18 5:17 AM, Manuel Reiter wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > ++ Description: > > When an if statement is not terminated by a fi, bash's error message is > not helpful in locating the problem. This is tough to do in a bison-generated parser. If som

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On 4/3/18 7:07 PM, PRussell wrote: > Hi, > > The error seems to be localized to the expansion of PS4 when "set -x" is > active. > > Please see sample script below. It's not quite that, though the expansion below does demonstrate what I think is the problem. If I am right about the cause, the p

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On 4/3/18 7:07 PM, PRussell wrote: > Hi, > > The error seems to be localized to the expansion of PS4 when "set -x" is > active. > > Please see sample script below. > > I am aware of the unusual parameter expansion for FUNCNAME. There might be a > local historical reason. :-) > > It does not

Re: Error message garbage when parameter expansion used inside (()) and variable unset

Hi, The error seems to be localized to the expansion of PS4 when "set -x" is active. Please see sample script below. I am aware of the unusual parameter expansion for FUNCNAME. There might be a local historical reason. :-) It does not happen outside of the PS4 expansion. It also behaves diffe

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On 4/3/18 1:15 PM, PRussell wrote: > Chet, is the output on opensuse running bash 4.4.19, correct? > > The specific output: > > ./t.sh: line 9: ���#V: var1 ==  : syntax error: operand expected (error > token is "==  ") > > archlinux has the same version of bash and I got the same results as on

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On Tue, Apr 03, 2018 at 12:15:14PM -0500, PRussell wrote: > ./t.sh: line 9: ���#V: var1 == : syntax error: operand expected (error > token is "== ") > > archlinux has the same version of bash and I got the same results as on > opensuse. I cannot reproduce this on Debian 9 amd64. Not with Debi

Re: Error message garbage when parameter expansion used inside (()) and variable unset

Chet, is the output on opensuse running bash 4.4.19, correct? The specific output: ./t.sh: line 9: ���#V: var1 == : syntax error: operand expected (error token is "== ") archlinux has the same version of bash and I got the same results as on opensuse. Below are the details of running ./

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On 4/2/18 5:16 PM, PRussell wrote: > Section 6.5 Shell Arithmetic says, > > "Within an expression, shell variables may also be referenced by name without > using the parameter expansion syntax. A shell variable that is null or unset > evaluates to 0 when referenced by name without using the parame

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On Mon, Apr 2, 2018 at 5:16 PM, PRussell wrote: > > echo 4B > ( set -x;var=5;var1=var; (( var1 == $var2 )) && echo yes || echo no ) > > > It appears that 3A and 4A evaluate to 0 because of the arithmetic context. > 3A echo's yes; 4A echo's no. > > The problem is what is happening with 3B and 4B

Re: Error message garbage when parameter expansion used inside (()) and variable unset

On Mon, Apr 02, 2018 at 04:16:54PM -0500, PRussell wrote: > The above tells us what happens to an unset variable if not using parameter > expansion. > > But if a shell variable uses parameter expansion and is null or unset, what > does it evaluate to inside (()) syntax? The parameter expansion

Re: Error: conflicting types for ‘sbrk’

Dear Eduardo, 2018-03-22 11:36 GMT-03:00 Eduardo A. Bustamante López : > On Wed, Mar 21, 2018 at 11:07:45AM -0300, Larissa Braz wrote: > > Hi, > > > > I found the following compilation error: > > > > xmalloc.c:51:14: error: conflicting types for ‘sbrk’ > > extern char *sbrk(); > >

Re: Error: conflicting types for ‘sbrk’

On Wed, Mar 21, 2018 at 11:07:45AM -0300, Larissa Braz wrote: > Hi, > > I found the following compilation error: > > xmalloc.c:51:14: error: conflicting types for ‘sbrk’ > extern char *sbrk(); > ^ > In file included from xmalloc.c:29:0: > /usr/include/unistd.h:1043:14: note: previ

Re: error: ‘eval_builtin’ undeclared

On 1/30/18 2:07 PM, Larissa Braz wrote: > I was running it using Ubuntu 14.04 LTS. I used the README instructions: > "To compile Bash, type `./configure', then `make'. " > > git clone http://git.savannah.gnu.org/git/bash > > ./configure > make >   > > T

Re: error: ‘eval_builtin’ undeclared

Hi, 2018-01-30 12:01 GMT-03:00 Chet Ramey : > On 1/30/18 8:51 AM, Chet Ramey wrote: > > > So if there's a problem with this kind of thing in gcc-4.8, I'd like to > > get some more information about what it is. > > I was running it using Ubuntu 14.04 LTS. I used the README instructions: "To compil

Re: error: ‘eval_builtin’ undeclared

On 1/30/18 8:51 AM, Chet Ramey wrote: > So if there's a problem with this kind of thing in gcc-4.8, I'd like to > get some more information about what it is. There doesn't seem to be. Running these commands on an ubuntu 14.04 system with gcc-4.8 results in a working bash binary: git clone http:/

Re: error: ‘eval_builtin’ undeclared

On 1/30/18 8:44 AM, Chet Ramey wrote: >> > I found the error bellow when I tried to compile the code. >> > >> > execute_cmd.c:4293:14: error: ‘eval_builtin’ undeclared (first use in >> this >> > function) >> >> That's interesting, since none of the patches mention eval_builtin

Re: error: ‘eval_builtin’ undeclared

On 1/30/18 8:39 AM, Larissa Braz wrote: > > 2018-01-30 10:34 GMT-03:00 Chet Ramey >: > > On 1/30/18 8:10 AM, Larissa Braz wrote: > > Bash version: last commit in repository ( > > http://git.savannah.gnu.org/cgit/bash.git >

Re: error: ‘eval_builtin’ undeclared

2018-01-30 10:34 GMT-03:00 Chet Ramey : > On 1/30/18 8:10 AM, Larissa Braz wrote: > > Bash version: last commit in repository ( > > http://git.savannah.gnu.org/cgit/bash.git) > > GCC version: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) > > > > Hi, > > I found the error bellow when I tried to

Re: error: ‘eval_builtin’ undeclared

On 1/30/18 8:10 AM, Larissa Braz wrote: > Bash version: last commit in repository ( > http://git.savannah.gnu.org/cgit/bash.git) > GCC version: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) > > Hi, > I found the error bellow when I tried to compile the code. > > execute_cmd.c:4293:14: error:

Re: error parsing file glob when importing function from environment

On 2/26/15 5:24 PM, Stephane Chazelas wrote: > 2015-02-26 16:35:14 -0500, Chet Ramey: >> On 2/26/15 2:37 PM, ad...@ptc.com wrote: >> >>> Bash Version: 4.2 >>> Patch Level: 47 >>> Release Status: release >>> >>> Description: >>> A bash function containing the syntax "files=( !(PAT) )" fails to p

Re: error parsing file glob when importing function from environment

On 2/26/15 2:37 PM, ad...@ptc.com wrote: > Bash Version: 4.2 > Patch Level: 47 > Release Status: release > > Description: > A bash function containing the syntax "files=( !(PAT) )" fails to parse > in a sub-shell when imported from the environment (to which it was exported > by the pare

Re: Error while building a static version of Bash 4.3.30

On 12/15/14, 6:59 AM, Sergey Mikhailov wrote: > Hello, > I've tried to build a static version of Bash 4.3.30 using these commands: > > export CFLAGS="-static -O2 -g" > export PATH="/usr/bin:$PATH" > ./configure --without-bash-malloc > make > > and got this error: > > ./lib/sh/libsh.a(shmatch.o):

Re: error message when rmail isn't installed

On 2/28/14 7:36 AM, Moe Tunes wrote: > When rmail isn't installed, bashbug makes a dead.bashbug file and prints an > error message saying rmail isn't installed. That error message could > include this mailing list address to make error reporting easier instead of > the end user having to search for

Re: Error on BASH man page

On 1/27/14, 12:06 AM, Dev Rana wrote: > > This line: > >if list; then list; [ elif list; then list; ] ... [ else list; ] fi > > The words "list" are underlined. On the second one, the underline > includes the ";", which makes it indistinguishable from a ":" - at least > on a gnome terminal.

Re: Error in read implementation and/or documentation

On 7/27/13 1:32 PM, Andreas Schwab wrote: > Chris Down writes: > >> Cannot reproduce. >> >> $ printf 01 | read -n3 >> $ echo $? >> 1 > > Try the same with input from the terminal. You are reading one character at a time, so ICANON is not set and ^D is an ordinary character. It's on

Re: Error in read implementation and/or documentation

OK, that makes sense. Sorry for being confused. I thought that by this level, ^D and EOF are equivalent. I should be able to check to see if the character returned is ^D, then act accordingly. Peter On 07/27/2013 03:10 PM, Chet Ramey wrote: On 7/27/13 1:32 PM, Andreas Schwab wrote: Chris Dow

Re: Error in read implementation and/or documentation

Chris Down writes: > Cannot reproduce. > > $ printf 01 | read -n3 > $ echo $? > 1 Try the same with input from the terminal. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely

Re: Error in read implementation and/or documentation

On 27 July 2013 17:17, Pierre Gaston wrote: > What is your test case? > I don't seem to be able to reproduce your problems, read returns > when it encouters EOF, and I get 1 if fewer bytes are read It seems it is something like this: $ read -n3 12^D$ echo $? 0

Re: Error in read implementation and/or documentation

On Sat, Jul 27, 2013 at 8:11 PM, Peter Olson wrote: > I was using ^D as an EOF. I guess I should have tried it in other ways. Is > ^D not the same as EOF? Sorry if that is a noob question. I was able to > reproduce all of your outputs. I am using xterm as my terminal emulator, if > that matters. >

Re: Error in read implementation and/or documentation

On Sat, Jul 27, 2013 at 7:37 AM, Peter Olson wrote: > According to "help read": > Options: > -n nchars return after reading NCHARS characters rather than > waiting > for a newline, but honor a delimiter if fewer than NCHARS > characters are read befo

Re: Error in read implementation and/or documentation

On 27 July 2013 19:32, Andreas Schwab wrote: > Chris Down writes: >> Cannot reproduce. >> >> $ printf 01 | read -n3 >> $ echo $? >> 1 > > Try the same with input from the terminal. Hm, that's a whole other problem then. I can reproduce this by following that path.

Re: Error in read implementation and/or documentation

I was using ^D as an EOF. I guess I should have tried it in other ways. Is ^D not the same as EOF? Sorry if that is a noob question. I was able to reproduce all of your outputs. I am using xterm as my terminal emulator, if that matters. Peter On 07/27/2013 10:35 AM, Chris Down wrote: Hello,

Re: Error in read implementation and/or documentation

Hello, On 27 July 2013 06:37, Peter Olson wrote: > If read is invoked with the -n or -N options, then given an EOF, it returns > with a zero exit status. Cannot reproduce. $ echo $BASH_VERSION 4.2.45(2)-release $ read -n1 In addition, if it is invoked with -n 3, for example, then g

Re: Error for large input files >2GB

I don't quite understand what your error report is saying, but when I was trying to read your script, I couldn't help noticing a few things: On Tue, Feb 07, 2012 at 06:24:11PM +0100, Hardy Flor wrote: > #!/bin/bash > > inputfile="" Actually it's just one file name. > leer_max=" "

Re: Error in manual for >&word redirection

On 10/12/11 4:07 PM, Greg Wooledge wrote: > Personally I wish all the csh compatibility features would go away forever, > but I appreciate that it's too late to remove them at this point. But > I think the manual should be updated to indicate that the >&word form > just plain fails for certain wo

Re: Error in manual for >&word redirection

On Thu, Oct 13, 2011 at 06:33:56AM +, Stephane CHAZELAS wrote: > 2011-10-12, 14:39(-06), Eric Blake: > > foo >&./1 > > Or > > foo >&! 1 > > or > > foo &> 1 > > or > > foo > 1 2>&1 So put those in the manual! ;-)

Re: Error in manual for >&word redirection

2011-10-12, 14:39(-06), Eric Blake: > On 10/12/2011 02:07 PM, Greg Wooledge wrote: >> Even using a space is not sufficient to force a valid file descriptor number >> to be treated as a filename: >> >> imadev:~$ foo>& 1 >> stdout >> stderr >> imadev:~$ ls -l 1 >> 1 not found > > If you want 'word'

Re: Error in manual for >&word redirection

On 10/12/2011 02:07 PM, Greg Wooledge wrote: Even using a space is not sufficient to force a valid file descriptor number to be treated as a filename: imadev:~$ foo>& 1 stdout stderr imadev:~$ ls -l 1 1 not found If you want 'word' treated as a filename, then express it as a filename. It's

Re: Error in manual for >&word redirection

Greg Wooledge writes: > Personally I wish all the csh compatibility features would go away forever, > but I appreciate that it's too late to remove them at this point. But > I think the manual should be updated to indicate that the >&word form > just plain fails for certain words, even with a sp

Re: Error building mkbuiltins on ia64-hp-hpux11.23

On 4/22/11 12:55 PM, Daniel Richard G. wrote: > +DD64 is from CFLAGS in the environment prior to configuration. Thanks, this is what I needed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc

Re: Error building mkbuiltins on ia64-hp-hpux11.23

On Fri, 2011 Apr 22 10:08-0400, Chet Ramey wrote: > > That's not what actually happens. CCFLAGS and CCFLAGS_FOR_BUILD share > a common set of options but differ in their use of CPPFLAGS and > CFLAGS. The link is done with LDFLAGS_FOR_BUILD. It's hard to tell > where the DD64 is coming from, since

Re: Error building mkbuiltins on ia64-hp-hpux11.23

On 4/22/11 12:07 AM, Daniel Richard G. wrote: > On Thu, 2011 Apr 21 16:36-0400, Chet Ramey wrote: >> >> What is the part of CFLAGS that fixes this, and why not just add it to >> CFLAGS_FOR_BUILD? CFLAGS_FOR_BUILD is for the `build tools' part of >> the builtins library. > > I believe the "+DD64"

Re: Error building mkbuiltins on ia64-hp-hpux11.23

On Thu, 2011 Apr 21 16:36-0400, Chet Ramey wrote: > > What is the part of CFLAGS that fixes this, and why not just add it to > CFLAGS_FOR_BUILD? CFLAGS_FOR_BUILD is for the `build tools' part of > the builtins library. I believe the "+DD64" bit is salient. (Generate 64-bit instead of 32-bit code.

Re: Error building mkbuiltins on ia64-hp-hpux11.23

> Building bash 4.2 on an HP-UX/Itanium system: > > gmake[1]: Entering directory `/tmp/bash-4.2.build/builtins' > rm -f mkbuiltins.o > cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I/tg/freeport/src/bash/bash--4.2 > -I/tg/freeport/src/bash/bash--4.2/include > -I/tg/freeport/src/bash/bash--4.2/lib

Re: Error Handling with bash script

Le 24/05/2010 17:05, Lenga, Yair a écrit: > I would like to propose an improvement to the bash error handling: > Add flag/option "err_return", that will cause a user defined shell > functions to immediately return, when a simple command will return a > non-zero status code. > The behavior is simil

Re: Error while executing bash in HPUX11.11

> coredumps while executing bash Version 4.0.33 > > /usr/local/bin#./bash > > /usr/lib/dld.sl: Can't open shared library: /usr/local/lib/libiconv.sl > /usr/lib/dld.sl: No such file or directory > > Abort(coredump) > > --- > > #ldd bash > > /usr/lib/libc.2 => /usr

Re: Error when script uses CRLF line endings w/ if stmt

Andreas Schwab schrieb: >> It's a character like 'A' or 'B'. > > 'A' and 'B' are letters, $'\r' is whitespace. Yes... :)

Re: Error when script uses CRLF line endings w/ if stmt

Jan Schampera writes: > It's a character like 'A' or 'B'. 'A' and 'B' are letters, $'\r' is whitespace. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: Error when script uses CRLF line endings w/ if stmt

Evan Driscoll schrieb: > Then, many programs don't handle them per se, but *not* handling them > doesn't cause much problem. grep, cat, and echo probably fall in this > category. Bash doesn't handle it. It's a character like 'A' or 'B'. It causes problems :) J.

Re: Error when script uses CRLF line endings w/ if stmt

[This is an combination of a couple of replies to the various emails since last evening.] Pierre Gaston wrote: cygwin's bash is patched and provides a special igncr shopt option. try shopt -s igncr And with the ability to pass options to Bash on invocation with -o, this provides a better solu

Re: Error when script uses CRLF line endings w/ if stmt

Jan Schampera a écrit : > Moreover, POSIX talks about "" here, which is a \n. Though I > didn't read through all the rationales, I just took a quick look, maybe > it's not limited to \n. '\n' can be two characters outside of POSIX, see "man fopen". - It would feel good to use C

Re: Error when script uses CRLF line endings w/ if stmt

According to Jan Schampera on 2/4/2010 10:39 PM: > drisc...@cs.wisc.edu schrieb: > >> Some of the time, using CRLF line endings cause syntax errors >> in Bash scripts ("unexpected end of file"). >> >> This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux, >> and Bash 3.

Re: Error when script uses CRLF line endings w/ if stmt

On Thu, Feb 04, 2010 at 11:54:51PM -0600, Evan Driscoll wrote: > Why not make Bash consider \r\n a legitimate line ending? What possible > reason could there be for treating carriage return characters as it does > now? Well, the most literal reason is that the shebang (#!/program) line will not

Re: Error when script uses CRLF line endings w/ if stmt

On Fri, Feb 5, 2010 at 7:54 AM, Evan Driscoll wrote: > Jan Schampera wrote: >> >> drisc...@cs.wisc.edu schrieb: >> >>>        Some of the time, using CRLF line endings cause syntax errors >>>        in Bash scripts ("unexpected end of file"). >>> >>>        This problem shows up on Bash 4.1 on Lin

Re: Error when script uses CRLF line endings w/ if stmt

Evan Driscoll schrieb: > echo a > echo b > seemed to work with both CRLF and LF endings. However, further > experimentation confirmed what you probably already know, which is that > it only appeared to work; in fact what was happening is that the CR > character was being passed to echo as part

Re: Error when script uses CRLF line endings w/ if stmt

Jan Schampera wrote: drisc...@cs.wisc.edu schrieb: Some of the time, using CRLF line endings cause syntax errors in Bash scripts ("unexpected end of file"). This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux, and Bash 3.2 on Cygwin (where I first noti

  1   2   >