Botched assertion in malloc]

CConfiguration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DSHELL -DHAVE_CON

Command substitution fails in here-document delimiter.

bbug1 Description: Binary data

Re: bug#54785: for floating point, printf should use double like in C instead of long double

Vincent Lefevre wrote in : $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))' 0xa.c00025cp-20 instead of 0xa.cp-20 To summarize, this test case is: printf '%a\n' 1.0251998901367188e-05 and the problem is that converting 1.0251998901367188e-05 to long doub

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/11/22 11:52, Chet Ramey wrote: On 4/9/22 3:31 PM, Paul Eggert wrote: It sounds like there are three cases. 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow    length modifiers for the printf utility), use long double. This would    work in both d

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks.

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/29/22 13:04, Chet Ramey wrote: I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. Come to think of it, as far as POSIX is concerned Ba

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/30/22 05:48, Vincent Lefevre wrote: Yes, but to be clear, POSIX says: shall be evaluated as if by the strtod() function if the corresponding conversion specifier is a, A, e, E, f, F, g, or G so the number should be regarded as a double-precision number (type double). Yes, but POSIX

Parallelization of shell scripts for 'configure' etc.

In many Gnu projects, the 'configure' script is the biggest barrier to building because it takes s long to run. Is there some way that we could improve its performance without completely reengineering it, by improving Bash so that it can parallelize 'configure' scripts? For ideas about thi

Re: Parallelization of shell scripts for 'configure' etc.

On 6/13/22 18:25, Dale R. Worley wrote: It seems to me that bash provides the needed tools -- "( ... ) &" lets you run things in parallel. Similarly, if you've got a lot of small tasks with a complex web of dependencies, you can encode that in a "makefile". It seems to me that the heavy work is

Re: Parallelization of shell scripts for 'configure' etc.

On 6/14/22 10:11, Nick Bowler wrote: The resulting config.h is correct but pa.sh took almost 1 minute to run the configure script, about ten times longer than dash takes to run the same script. More than half of that time appears to be spent just loading the program into pa.sh, before a single

Re: Parallelization of shell scripts for 'configure' etc.

On 6/14/22 18:55, Ángel wrote: Do you have any handy example of configure that takes too long to run? Sure. Coreutils, emacs. Pretty much any nontrivial configure script takes longer than it should. I understand that parallelization of shell scripts is nontrivial.

[PATCH] Don't dump core if localtime returns NULL

* examples/loadables/stat.c (stattime): * examples/loadables/strftime.c (strftime_builtin): * lib/readline/examples/histexamp.c (main): * parse.y (decode_prompt_string): Do something reasonable if localtime returns NULL. This can happen, for example, if someone sets the system clock to such an absu

[PATCH] Work around GNU/Linux timestamp glitch

Without this patch, Bash can hand out user-visible timestamps that are out of order, because on GNU/Linux the 'time' function uses a different clock than file timestamps and the 'gettimeofday' function. See . * include/posixtime.h (getnow): Ne

Bash not portable to C23

I see that Bash won't compile with a C23 compiler, since it still uses old-style function definitions which C23 no longer supports. Is there any effort and/or interest in fixing this portability problem in Bash? It's OK these days to assume C89 or later, so it's OK for Bash to switch to new-st

Re: [PATCH] Work around GNU/Linux timestamp glitch

On 3/23/23 17:51, Koichi Murase wrote: By the way, you should prepare patches based on the devel branch of Bash. Thanks for letting me know; I'll resend based on devel.

Re: Bash not portable to C23

On 3/23/23 18:23, Lawrence Velázquez wrote: On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote: I see that Bash won't compile with a C23 compiler, since it still uses old-style function definitions which C23 no longer supports. Is there any effort and/or interest in fixing this portab

[PATCH v2 2/2] Work around GNU/Linux timestamp glitch

Without this patch, Bash can hand out user-visible timestamps that are out of order, because on GNU/Linux the 'time' function uses a different clock than file timestamps and the 'gettimeofday' function. The out-of-order timestamps can lead to user-confusion. https://sourceware.org/bugzilla/show_bug

[PATCH v2 1/2] Don't dump core if localtime returns NULL

* examples/loadables/stat.c (stattime): * examples/loadables/strftime.c (strftime_builtin): * lib/readline/examples/histexamp.c (main): * parse.y (decode_prompt_string): * support/man2html.c (print_sig): Do something reasonable if localtime returns NULL. This can happen, for example, if someone set

[PATCH] Port lib/sh/tmpfile.c to hosts without mkdtemp

* lib/sh/tmpfile.c (sh_mktmpdir) [!USE_MKDTEMP]: Fix use of undeclared var 'fd'. --- lib/sh/tmpfile.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/sh/tmpfile.c b/lib/sh/tmpfile.c index 18582b10..610bd3dc 100644 --- a/lib/sh/tmpfile.c +++ b/lib/sh/tmpfile.c @@ -311,1

[PATCH] Pacify gcc -Wpointer-to-int-cast

* lib/sh/random.c (genseed): Use a different type, to pacify GCC "warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]" on platforms with 64-bit pointers and 32-bit int. --- lib/sh/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/sh/random

[PATCH 3/4] Port unwind protection to C23

Do not assume that all pointers have the same representation at the machine level and that address space is linear, as the C standard does not guarantee this and it is not true on a few unusual platforms. Fixing this also uncovered a bug on conventional 64-bit platforms, where the call 'add_unwind

[PATCH 4/4] Assume __STDC__ if it merely assumes C89 or later

There's no longer any point to worrying about K&R compilers as the code won't work with them anyway. Simplify the code by omitting __STDC__ tests when that merely is checking for C89 or later, as we assume C89 prototypes now. --- aclocal.m4| 15 --- builtins/enable.def

[PATCH 2/4] Remove no-longer-used K&R cruft

Since we now assume C89 function prototypes anyway, remove no-longer-used cruft that is used only for ports to compilers requiring K&R style. --- aclocal.m4 | 35 + builtins/common.c | 23 ++ builtins/mkbuiltins.c | 4 --- builtins/pri

[PATCH 1/4] Port more functions etc. to C23

Port more function definitions and declarations to C23. This includes adding a return type when it defaulted to int. Add some casts to and from GENERIC_LIST * that are needed now that the list functions are prototyped. This does not finish the job, as some trickier functions still won't work with

Re: Bash not portable to C23

On 2023-03-24 12:04, Chet Ramey wrote: However, Bash's devel branch still has old-style function definitions and therefore won't compile with a strict C23 compiler. For example, get_variable_value in variables.c is old-style. I assume there would be interest in fixing remaining areas where Bash

Re: [PATCH 3/4] Port unwind protection to C23

On 2023-03-26 21:17, Martin D Kealey wrote: While C has never guaranteed that pointers all have the same size & alignment, POSIX does provide this guarantee, although indirectly (it has to be true for dlsym() to work, for example). My commit message was a bit misleading, as the problem is not l

Re: bug#65659: RFC: changing printf(1) behavior on %b

On 2023-08-31 08:35, Eric Blake wrote: Typing-wise, %#s as a synonym for %b is probably going to be easier (less shell escaping needed). Is there any interest in a patch to coreutils or bash that would add such a synonym, to make it easier to leave that functionality in place for POSIX Issue 9 e

test -lt inconsistent about white space

ter the integer. This is inconsistent: Bash should treat trailing whitespace the same way it treats leading whitespace, and should accept all of doit's 'test' commands, as Dash does. Proposed patch attached.From bb2403a3ae6a39631777a7deea3d7f8128fff764 Mon Sep 17 00:00

Re: test -lt inconsistent about white space

On 2023-10-28 18:41, Oğuz wrote: Why? The same commands fail on bosh, yash, and zsh too. I don't know what bosh is. zsh and yash prohibit trailing spaces in integers, but allow leading spaces: % test ' 3' -lt ' 4' % test ' 3 ' -lt ' 4 ' test: integer expression expected: 3 Presumably

Re: test -lt inconsistent about white space

On 2023-10-29 03:18, Oğuz wrote: I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this. If that's the intent, which is self-consistent but which disagrees with all other shel

Re: test -lt inconsistent about white space

On 2023-10-30 08:09, Chet Ramey wrote: The fact that this whitespace issue hasn't been reported since then shows how obscure it is. Yes, I noticed it only because coreutils 'test' was incompatible with Bash. (It was also incompatible with everybody else!) I recently changed bleeding-edge cor

Re: multi-threaded compiling

On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > I've attached the problem. It consists of two parts: > > 1) multi-threaded bash script and / or multi-threaded Makefile > > Running bash script functions as expected, but executing the same > line of code with make and / or the command line

Re: multi-threaded compiling

On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote: > The actual command invocations (a Makefile, a make.sh script) can be > found in the attachment, as indicated on the first line of the mail. > In the attachment there are two directories, one and two, belonging > to 1) and 2) respectively. Th

Re: multi-threaded compiling

On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote: > /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop > variable This is because of the issue I mentioned in my initial reply. This invocation is using /bin/sh which is a POSIX shell but is not bash; probably it's das

Re: multi-threaded compiling

On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote: > You won't be able to take advantage of "wait -n"'s ability to react > to the first job that finishes.  You'll end up reaping each job in > the order they started, not the order they finished. It feels to me like you're trying to reproduce m

Bash printf should diagnose integer overflow

r, for simplicity these patches do not use all the Gnulib machinery for . These patches can be applied to Bash's devel branch (commit 54f3ed2278025081f897b9bd958fcf099fd5be18 dated Mon Mar 4 14:59:33 2024 -0500) by using the command "git am".From 1f96

Re: multi-threaded compiling

On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > I'd still like to hear why you aren't simply using "make -j". > > That's because I don't want to define static compile and link targets > for every new project I start. The Makefile in question contains only > a few lines of code and some

Re: Bash printf should diagnose integer overflow

a97743ad86f6db6f3b84c78207a78 dated today at 09:33:32 -0400. From 4ca64cfc3de1d9cf75490b85891e88fbf0405538 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 13 Mar 2024 17:00:17 -0700 Subject: [PATCH 1/5] printf now diagnoses underlying printf failure * builtins/printf.def (printf_builtin)

Re: Bash printf should diagnose integer overflow

On 3/18/24 07:40, Chet Ramey wrote: Thanks for the patches. They introduce a number of regressions, some due to the different overflow handling; several not. I urge everyone who submits non-trivial patches to run the test suite (`make tests') on their patched versions before sending them in. I

Re: Bash printf should diagnose integer overflow

t;git format-patch" format so you can use "git am" on them. If there's some reason a patch shouldn't be applied please let me know so that I can stop worrying about that subissue.From ccf906084c3aaf7cd75f0ee1e035986af7d58a82 Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: Bash printf should diagnose integer overflow

On 2024-03-21 13:31, Chet Ramey wrote: Interesting. I can't reproduce this. Using the commit to which your patches apply, without applying any of them, on a fresh Virtualbox Fedora 39 install, I get consistent `make tests' output every time. I just now tried the latest devel commit (b1e7f6803

Idle timer to trigger vlock?

T=7200 but this logs them out, which is inconvenient. I just want to lock their session, requiring them to enter their password to unlock the session, similar to how xscreensaver would do if they were using a GUI. Thanks Paul

'exec

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/local/cs/ba

print function in /examples/functions/kshenv

extent by modifying the function, but was wondering if anyone has a more accurate/efficient/ official/distributed version. Thanks. Paul

Bash loops and otherwise mishandles long lines

Here's how to reproduce the problem: (printf 'ln ' perl -e 'print "x"x(2**31)' printf ' ' perl -e 'print "x"x(2**30)' printf '\n' ) >bigscript bash bigscript On my x86-64 host, Bash loops, seemingly forever. I expect it's using a 32-bit integer to keep track of line lengths, somewhere. This

Re: locale specific ordering in EN_US -- why is a

On 06/28/2013 09:48 AM, Paolo Bonzini wrote: > I may even agree, but the fact remains that until you fix it in glibc, > you have not fixed it. As long as glibc doesn't change, there's no > point in changing everything else. Unfortunately, one reason to change glibc is: "Ouch! all these GNU applic

Re: stty settings override ~/.inputrc?

trc, update the stty settings to match as closely as possible, so that re-reading the same stty settings for the next command won't change anything. That way, .inputrc wins (persistently) over the original stty settings, but later changes to stty settings still

Re: bash expr problem/bug... 0$val

[EMAIL PROTECTED] wrote: > # a=500; b="0$[a]"; c=$[b]; echo -e "a: $a\nb: $b\nc: $c\n" > a: 500 > b: 0500 > c: 320 man bash, under ARITHMETIC EVALUATION: Constants with a leading 0 are inte

shared library installation

readline/shlib/Makefile uses INSTALL_DATA to install shared libraries. INSTALL or INSTALL_PROGRAM would seem more appropriate; at least on GNU/Linux, gcc creates shared libraries with the execute bit set, and ldd warns if it is not set. paul ___ Bug

Re: failure in pipeline not reflected in $?

[EMAIL PROTECTED] wrote: > If a command in a pipeline of commands fails, there appears to be no > way of knowing this. Check the man page regarding the PIPESTATUS array. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.g

Re: pipeline outlives TERMed bash

ng others). Instead, move logger into a separate /service/foo/log/run script. http://cr.yp.to/daemontools/faq/create.html#runlog> For more help with daemontools, try [EMAIL PROTECTED] or [EMAIL PROTECTED] paul ___ Bug-bash mailing lis

coordinating bash and coreutils: which bash?

A few months ago we went through a POSIX-compatibility sweep of coreutils, and in my nonexistent spare time I'd like to migrate some of those fixes into the Bash builtins that duplicate coreutils. Conversely, I'd like to migrate any fixes made by Bash in this area into coreutils. Which version of

Re: ansi escape sequences in prompt mess-up the command prompt

Antonis <[EMAIL PROTECTED]> wrote: > Using ansi escape sequences in the prompt causes Bash to incorrectly > calculate the available width of the terminal and messes-up the command > prompt when a certain amount of characters are typed in. See entry E3 in the b

Re: programmable auto completion with embedded ":" not working?

iables like $PATH. Check the man page for COMP_WORDBREAKS. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: error in math args?

Scott Dylewski <[EMAIL PROTECTED]> wrote: > I get an error when running: > echo $(( 008 / 2 )) Numbers starting with 0 are interpreted as octal, and so can only use digits 0-7. You'll have to strip off the leading zeros to make the number be interpreted a

Re: HERE document mystery

nt must also be entirely inside $(). Move the closing ) after "BAD". 2. [0-9]* matches every line, since * matches 0 or more occurrences. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Can't get the set-user-id bit to work

h those permissions, only the root user and root group can create files in /tmp. To allow all users to create files there, make it world-writable and sticky: # chmod 1777 /tmp # ls -ld /tmp drwxrwxrwt 13 root root 4096 Dec 27 16:50 /tmp paul ___ Bug-

Re: Can't get the set-user-id bit to work

ons in /etc/passwd and /etc/group aren't involved. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: "echo: write error: Broken pipe" even when DONT_REPORT_SIGPIPE set

Chet Ramey <[EMAIL PROTECTED]> wrote: > `echo' now displays an error message on write errors. In the case of a SIGPIPE trap, is it intended that echo sees EPIPE before the SIGPIPE handler runs? paul ___ Bug-bash mailing list Bug-bas

Re: Conditional expression problem: both "-a file" and "! -a file" return true

guidance for deciding whether ! is an operator or operand in any particular case. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: can't expand after colon

Dan Jacobson <[EMAIL PROTECTED]> wrote: > Must one use \: to make this work? That, or adjust $COMP_WORDBREAKS to not include ":". paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Possible bash bug when dealing with CR/LF in variable expansion

> [EMAIL PROTECTED]:~/bash/bash-3.1$ zak="${zak}karin" > [EMAIL PROTECTED]:~/bash/bash-3.1$ echo $zak | od -t x1 > 000 0d 6b 61 72 69 6e 0a > 007 Again, the newline comes from echo, not from zak. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: exit somtimes not exit's the script

[EMAIL PROTECTED] wrote: > a exit inside a loop inside a pipe exits's the loop and not the > script. may bee a error. This is normal. Each element of a pipeline is run in a child process. paul ___ Bug-bash mailing list Bug-b

Re: problem ? bug ?

[EMAIL PROTECTED] wrote: > [kaneda<-ogorasek]~$if [ ! -a /etc/passwd ] ; then echo si ; fi -a is used as a binary "and" operator here. The expressions "!" and "/etc/passwd" are nonempty strings, so both are considered true, an

Re: eval in functions in pipelines doesn't set variables globally

h FAQ, entry E4. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: BUG: ls -ld directory/

s you the behavior you want. If you can't find it, you can write to bug-coreutils@gnu.org to submit a feature request. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: trap handler scope wrong?

gt; I'm a bit worried though about hard coding the fd 3. Is there a way > to get the next available fd number and save it in a variable, > rather than hard code 3? Unfortunately, no. You could use a higher number, which would be less likely to

Re: How to suppress async messages for background jobs

gt; ? If you don't need to refer to the process as %1, etc.: $ ( kwrite & ) I have this in my .bashrc to I can use alt-Enter to run something in the background without keeping track of it as a shell job: bind $'Meta-RET: "\001(\005&)\r"' paul __

Re: document that echo can't be given a NULL

Dan Jacobson <[EMAIL PROTECTED]> wrote: > No way to hand echo or /bin/echo a NULL. For /bin/echo, that's because execve() uses null-terminated strings. For bash's builtin echo, it could be done, but then it would be inconsistent with external commands, which might be

Re: Using variables in variables names

mes, it isn't treated as an assignment. This will work: ac=12 eval "dings$ac=wasannersder" paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Using variables in variables names

"Dirk H. Schulz" <[EMAIL PROTECTED]> wrote: > Paul Jarc schrieb: >> ac=12 eval "dings$ac=wasannersder" > > And how do I reference it then? ac=12 eval "value=\$dings$ac" echo $value Or: ac=12 name=dings$ac echo ${!name} paul _

Re: Question about variables and for loop

XXX might start with "-", then it takes a little more work to ensure it isn't misinterpreted as an option to "set": eval "set x $XXX" shift paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

Henrik Nordstrom <[EMAIL PROTECTED]> writes: > sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert: > >> Autoconf deals with shells that do not conform to XSI, and where the >> results are implementation-defined if there's a backslash anywhere in >> the stri

Re: Grouped pipeline clobbering question

ount of data from the pipe, although it will print only as much as you tell it to. To get the behavior you want, you'll have to duplicate head's behavior in sed: cat file | sed -e '1,10{p;d;}' -e x And in this case, cat is unnecessary too: s

Re: echo "enhancement" leads to confused legacy script tools...

Andreas Schwab <[EMAIL PROTECTED]> writes: > But note that bash interprets -n as an option, which is not compliant with > XSI. Bash doesn't claim conformance to XSI, so that's OK as far as Bash is concerned. Autoconf (and I assume Squid) is supposed be portable to all POSIX hosts, not merely POS

Re: echo "enhancement" leads to confused legacy script tools...

Linda W <[EMAIL PROTECTED]> writes: > I believe bash is broken in regards to using "any" number after > "\" as an octal value. The shell specifications require the leading > zero for an octal constant I'm afraid this is backwards. This POSIX+XSI requirement constrains applications, not implemen

Re: echo "enhancement" leads to confused legacy script tools...

Andreas Schwab <[EMAIL PROTECTED]> writes: >> There's a little history here. POSIX 1003.2-1992 said that echo has >> implementation-defined behavior if given any options, or if any > > Are you sure about "any option"? The current spec only talks about -n. Yes, I have the printed copy of POSIX 1

Re: bash ignoring .inputrc (or am I dumb)

William Yardley <[EMAIL PROTECTED]> wrote: > I would still like to know if there's a way to bind ^W to > backward-kill-word within bash, so if anyone has suggestions, I'd > appreciate them. Check out the "bind" builtin command in

Re: pattern matching: range expression

Wolf-Rainer Novender <[EMAIL PROTECTED]> wrote: > e.g. ls [A-Z]* should yield in all names starting with capital letters. > Does not work! I get >>all<< names! http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-

Re: Selinux bash prompt decorations

that people using this in a classified environment have an > easy way to see what the session is running at. You can put the information in PS1 without bash having special functionality for getting it. selinux_user=`...` PS1='$selinux_user...' paul _

Re: test -f with no args is true

an operator. This is how all shells behave, and what POSIX/SUS says they should do. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

his case, but then fail if foo contains newlines: > foo="a > b > c" What do you mean by "fail"? What do you want to happen in this case? paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Thursday 04 May 2006 00:44, Paul Jarc wrote: >> What do you mean by "fail"? What do you want to happen in this case? > > i meant gawk hates it ... not bash Ok, and what about the second question? What are you trying

Re: Selinux bash prompt decorations

chanisms like command substitution, is not good. Interdependencies should be kept to a minimum, and pushed to as high a level as possible. Instead of modifying bash to call some standardized get_security_role() function, put a standardized `get-security-role` c

Re: How to use [[ string =~ regexp ]]?

uot;^" to anchor the pattern to the beginning of the string, and "$" to anchor it to the end: [[ string =~ ^[a-z]$ ]] paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: here document and STDIN

it to another descriptor: sh < So I can run some Perl code inside like, > > perl - <<'EOF' > X > > EOF With perl, it may be easier to use -e instead of a here document: perl -e ' X ' Then perl will still be connected to the original

Re: here document and STDIN

I wrote: > sh < read <&3 > EOF Sorry, that first line should be: sh 3<&0

Re: here document and STDIN

-e ' ... '\'' ... ' >From the shell's point of view, this is a single-quoted string, adjacent to a backslash-escaped single quote, adjacent to another single-quoted string. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: EOF does not work in echo

that it should send EOF to the program reading from the terminal. Control-D is also used in other contexts (such as typing at a terminal in "raw" mode) to produce the character 004. In the case of a pipe, a reader will not see EOF until all writers have c

Re: Aliases fail in command substitution in noninteractive mode.

expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below). paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash expansion nuance or bug?

ls: ls: No such file or directory. man bash, under ALIASES: # If the last character of the alias value is a blank, then the next # command word following the alias is also checked for alias # expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: while do done has problems with global variables

[EMAIL PROTECTED] wrote: >ls -1 | while read f; do Read entry E4 in the bash FAQ. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: terminating lines with accidental eof

tement of what /bin/sh does was ambiguous since you had not specified which /bin/sh you're using. > command history browsing must, similarly, present "commented" > commands in case thay are executed as a result of this issue. Has anyone verified that t

Re: automatic code generation

... eval "cat < output-file paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Python and Bash

ending SIGINT to both bash and python. python will process SIGINT by throwing a KeyboardInterrupt exception. Have you checked to see how that exception is handled in your script? If it's begin caught and ignored, that's the best place to fix it. paul _

Re: !* goofs here-strings

mwoehlke <[EMAIL PROTECTED]> wrote: > I thought the syntax was only two '<'s? "<<" gives you a here-document. "<<<" gives you a here-string. Check the man page for details. paul ___ Bu

Re: null command and parameter expansion for "Display error if null or unset"

t do anything. The contents of $FAKEVAR, if any, are just passed as arguments to :, which does nothing. Since the expansion isn't quoted, word splitting and pathname expansion are applied - that's extra useless work, but not harmful. paul ___

Re: null command and parameter expansion for "Display error if null or unset"

an unset variable and a variable set to an empty value. If that distinction is important, you can use: test "${FAKEVAR+set}" = set You can also wrap it up in a function for convenience: is_set() { eval "test \"\${${1?}+set}\" = set" } paul __

Re: unable to capture return value using backticks and local

. To get the status from a backtick command, you need the assignment to be alone, not part of another command: foo() { local TICKED TICKED=`false` echo RV: $? } paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bug with 'test' built-in.

e two, since it pulls the "!" outside the test and leaves only two arguments for the test to examine.) You could also remove "!" and switch your "then" and "else" clauses, which works with any shell. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

  1   2   3   >