Re: "printf %d ''" should diagnose the empty string

On 2024-11-20 23:25, Martin D Kealey wrote: 2. There exist deployed scripts that rely on the current behaviour. Where? Any such scripts won't work on other shell implementations that do conform to POSIX here. This behaviour is entirely consistent with strtol(arg,&end,0) where you only che

Re: "printf %d ''" should diagnose the empty string

On 2024-11-20 07:31, Martin D Kealey wrote: From a semantic perspective, because "" doesn't contain any non-digits. Under that argument, "printf %d -" shouldn't report an error either, because "-" doesn't contain anything other than what could appear in an integer. Anyway, this isn't an is

"printf %d ''" should diagnose the empty string

s should behave like "printf %d ' '", and should output a diagnostic and exit with status 1; instead it silently exits with status 0. Fix: Attached.From f2583bf297268c08b474c68b0a8a2188f8d555cf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 19 Nov 2024 11:35:21 -08

Re: "printf %d ''" should diagnose the empty string

On 2024-11-19 13:05, #!microsuxx wrote: u can try posix mode if u care Certainly if Bash is in POSIX mode it should reject "printf %d ''", for the same reason it rejects "printf %d ' '" and "printf %d x" - POSIX requires it to diagnose any argument that isn't a C integer context. However, I

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

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

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: 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

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

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 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 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: 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: 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-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

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: 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

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: 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

[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

[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 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 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] 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] 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 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

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

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.

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

[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

[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

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.

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/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

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: 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

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/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/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

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

Command substitution fails in here-document delimiter.

bbug1 Description: Binary data

Re: Broken $! behavior

Thank you Chet - much appreciated. On Wed, 7 Oct 2020 at 16:41, Chet Ramey wrote: > On 10/7/20 7:56 AM, Paul Fox wrote: > > It seems like consecutive $! are mis-processed. This has always worked - > > since csh days and bash 1.x. But sometime after 4.1 or 4.2, it got > br

Broken $! behavior

It seems like consecutive $! are mis-processed. This has always worked - since csh days and bash 1.x. But sometime after 4.1 or 4.2, it got broken. Heres my system info and version data /home/fox/src/proc@allie: cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic D

Re: CTRL-C on command line does not cancel current command

reset’ to no avail. I know it’s such a minor issue, but it’s one of those that keeps biting me throughout the day because of the way I’m trained. I realize I can use CTRL-U, but... Anyway, here is a snapshot of what you were asking. I haven’t used readline much, if at all. Thanks. Paul

Re: CTRL-C on command line does not cancel current command

Only seeing this on Alpine BusyBox (iSH) on iOS 13.x with either 5.0.11 or 5.0.17 > On May 8, 2020, at 2:19 PM, Chet Ramey wrote: > > On 5/8/20 3:19 PM, Paul Kelaita wrote: > >> Machine Type: i586-alpine-linux-musl >> >> Bash Version: 5.0 >> Patch

CTRL-C on command line does not cancel current command

Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-musl Compiler: gcc Compilation CFLAGS: -Os -fomit-frame-pointer -g -Wno-parentheses -Wno-format-security uname output: Linux PuPadPro 3.2.0-ish iSH 1.0 (67) May 4 2020 00:20:06 i686 Linux Machine Type: i5

Re: issues in bash found while creating command result display

On Tue, 2019-04-16 at 14:57 -0400, Chet Ramey wrote: > Why take so much effort to (imperfectly) figure out and display > things you already know? Correctness. If what the user knows doesn't match what the program knows then they might think that the program is buggy or that there is something mal

Re: issues in bash found while creating command result display

On Tue, 2019-04-16 at 12:38 +0700, Robert Elz wrote: > That's really hard to do and do correctly. I was operating on the assumption that it could be done in the same way that the $? and $PIPESTATUS variables are created/updated. > There's no way to pass variables back from a subshell I think I

Re: issues in bash found while creating command result display

On Mon, 2019-04-15 at 17:31 -0400, Chet Ramey wrote: > You can use $HISTCMD with a slight fix that's now in the devel branch. That doesn't increment when you use HISTCONTROL=erasedups AFAICT but the command number does increment. Also HISTCMD doesn't start at zero. > The Korn shell uses values >

Re: issues in bash found while creating command result display

On Sun, 2019-04-14 at 17:28 -0400, Chet Ramey wrote: > That's the number of positional parameters. Oops, I mean the command number variable \# that is available at PS1 evaluation time but not when PROMPT_COMMAND is run. I was able to workaround this by deferring the decision to display the status

issues in bash found while creating command result display

Hi folks, I wanted a way in bash to print the status of the last command I ran, including information about each command in a pipe and about signals. I noticed that bash does not have the ability to display a command result, so I came up with the attached prompt configuration. I am hoping that f

case pattern checking with bash -n fails

her variations: (+([[:alpha:]])*([[:alnum:]-_])) (@([[:alpha:]])*([[:alnum:]-_])) [[:alpha:]]*([[:alnum:]-_])) ... Didn't work. All fail bash -n. Please advise. -- cul8er Paul paul.foers...@gmail.com

Re: Buffer corruption when the terminal is resized.

can press ^L to clear/repair the screen, or ^C to > cancel the command and start over, or anything alike. It's sure a bit > annoying, but IMO nothing big deal. > > In the mean time I'm wondering... does the workaround of disabling wraparound > while the prompt is prin

Re: Buffer corruption when the terminal is resized.

Is there a flag in macOS's Terminal? It's because I am also experiencing this bug on macOS's Terminal :) (with bash). On Mon, Jun 12, 2017 at 9:47 PM, Chet Ramey wrote: > On 6/12/17 3:45 PM, Paul Peet wrote: >> Well, I can try to re-open this issue on the gnome-terminal

Re: Buffer corruption when the terminal is resized.

wrote: > On 6/12/17 2:24 PM, Paul Peet wrote: >> I guess this is why I don't get the garbage output with gnome-terminal >> and dash. Dash doesn't use readline apparently. > > Dash doesn't support line editing at all out of the box, though you can > build it us

Re: Buffer corruption when the terminal is resized.

I guess this is why I don't get the garbage output with gnome-terminal and dash. Dash doesn't use readline apparently. So, what can be done to actually fix this? On Mon, Jun 12, 2017 at 7:55 PM, Chet Ramey wrote: > On 6/12/17 1:38 PM, Paul Peet wrote: >> Uhmm, I am not su

Re: Buffer corruption when the terminal is resized.

at 6:35 AM, Eduardo Bustamante wrote: > On Sun, Jun 11, 2017 at 12:29:33AM +0200, Paul Peet wrote: > [...] >> Unfortunately, I am still getting the same behavior as before (This >> also happens with xterm for some reason.) > > Please do consider that Readline has little kn

Re: Buffer corruption when the terminal is resized.

VERSION 4.4.12(1)-maint Unfortunately, I am still getting the same behavior as before (This also happens with xterm for some reason.) On Sat, Jun 10, 2017 at 11:20 PM, Eduardo Bustamante wrote: > On Sat, Jun 10, 2017 at 07:21:36PM +0200, Paul Peet wrote: >> If I understand this correctly t

Re: Buffer corruption when the terminal is resized.

t still results in a corrupted buffer. I've uploaded another gif which shows this: https://media.giphy.com/media/xUA7biW8UtwYIU6ggg/giphy.gif On Sat, Jun 10, 2017 at 6:58 PM, Eduardo Bustamante wrote: > On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote: >> declare -

Re: Buffer corruption when the terminal is resized.

> On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote: > > I would like to report a bug with bash (readline?). This bug can be > reproduced by opening gnome-terminal with bash running. By quickly > horizontally resizing the terminal window you can see that the buffer > seems to b

Buffer corruption when the terminal is resized.

I would like to report a bug with bash (readline?). This bug can be reproduced by opening gnome-terminal with bash running. By quickly horizontally resizing the terminal window you can see that the buffer seems to be corrupted as you see repeated or even removed lines or characters. At first I tho

Re: smart indented HERE docs

I agree something like this would be nice. Especially if it could handle spaces (in addition to tabs). My current solution to this problem is not particularly pretty or elegant: #!/bin/bash alias CAT_TO_END="I=\"\${I/*\$'\n'/}\" ; alias START=\"perl -ple 's/^\$I//' <<'\${I}END' ; unalias START\

web page has a misspelling (typo) "discus" should be "discuss"

>From https://www.gnu.org/software/bash/ > Mailing lists > > To ask for help about bash, bash programming or bash shell scripting please > use the mailing list. To report bugs or to DISCUS most > aspects of developing bash please use the mailing list.

Bash 4.4-rc1 incompatibility with future Emacs $EMACS

Please see attached patch. Fix: Please see attached patch. From 75d409f43d09d1323416db90121bc6bf54cbc3ff Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 8 Apr 2016 11:22:39 -0700 Subject: [PATCH] Fix compatibility problem with INSIDE_EMACS etc. The checks for deciding whether bash is bei

Bash should look at INSIDE_EMACS not just EMACS

t; chapter of the Emacs manual http://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html this variable is obsolescent and software is supposed to use the variable INSIDE_EMACS instead. Repeat-By: Run a future version of Emacs, which do

Bugs in ERR and RETURN traps

I posted bug reports at https://savannah.gnu.org/support/index.php?108738 and https://savannah.gnu.org/support/index.php?108749 but there seems to be very little activity (or none at all?) on the issue tracker, so I figured it might be a good idea to post to the mailing list too. I'm using bash

Environment parsed for Functions when invoked as rbash (and sh)

is message has not been reviewed nor approved by any entity whatsoever. I should not be considered an "AUTHORITY" on any subject. - Paul FM Info: http://www.umn.edu/~paulfm/ -

Re: Bash security issue

On Fri, 2014-09-26 at 10:51 -0400, Steve Simmons wrote: > 2) build a 'real' /bin/sh without those compiled in. This begs the > definition of 'real', but IMHO if it's not in POSIX, it shouldn't be > in 'real' /bin/sh Ubuntu and it's derivatives have been doing this since 2006. /bin/sh on these sys

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

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

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

'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

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

Re: command not put into history if it starts with space

Mike, Thanks, I was unaware of HISTCONTROL. Paul On 6 February 2010 09:06, Jan Schampera wrote: > Mike Frysinger schrieb: > >>> When using the bash shell in an xterm or rxvt terminals at least, >>> commands executed which start with a space, eg " ls" are

command not put into history if it starts with space

Press Ctrl-p or type "history | tail". Observe that last command starting with space is not in present in the command history. Thanks, Paul Stansell

Re: Incorrect alias substitution

xpanded by a non-interactive bash by default. If you do "shopt -s expand_aliases", then they'll be expanded. paul

Re: Pausing a bash script

r use it. You could put "&&" after every command, to ensure that the script will stop at the first command that fails. That's what I generally do. Or, if the ftp command is the only one whose success you care about, you could use "if": ... if ftp_command; then echo the transfer was successful else exit fi ... paul

Re: Help: Bash script that show you the last file created?

Mike Frysinger wrote: > the op wasnt asking for the time, they were asking for the last created file. > > and the ls man page talks how to sort by ctime. ctime is the time when the inode was last modified, not (necessarily) the time when the file was created. paul

Re: Help: Bash script that show you the last file created?

This will show the most recently modified one of those files: ls -t /home/server/backups/local_backups/*/server/mysql/*.sql | sed q paul

Re: No tilde expansion right after a quotation

sion. When not performing substring expansion, bash tests for a parameter that is unset or null; omitting the colon results in a test only for a parame- ter that is unset. paul

Re: No tilde expansion right after a quotation

as often set as is $#. They're both always set; pick whichever one you like. paul

Re: No tilde expansion right after a quotation

Jon Seymour wrote: > On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote: >> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah} > > Out of interest, how does one derive that outcome from the documented > behaviour of bash? That is, which expansion rules are being invoked? It's $

Re: No tilde expansion right after a quotation

that can fail for reasons external to the bash process. Here's another possibility: CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah} paul

Re: Option "-n" not working reliably and poorly documented

r, since -n suppresses > command execution. -n *doesn't* report an error, because it only checks that the script satisfies the shell grammar. It doesn't verify that the arguments of builtin commands are meaningful. paul

Re: Option "-n" not working reliably and poorly documented

he "-n" option in the description of the "-D" option: "This implies the > -n option; no commands will be executed." It's documented under the "set" builtin. paul

Re: Declaring variables as local effects command status $?

Michael Rendell wrote: > local x=$( echo hi; exit 20); > ret=$? Here you're getting the exit status of "local" itself, which is 0. If you want the exit status of the command substitution, make that a separate command: local x x=$( echo hi; exit 20); paul

Re: Migrating from tcsh to bash (issues)

pand the ~. My aim is to get to show the full pathname at all times. Use $PWD. I don't know about #3 or #4. > 5. Is there an option in bash to print the exit value of commands? You can use $? or ${pipestat...@]} in $PS1 or $PROMPT_COMMAND. paul

Re: truncating the path in the bash prompt?

/src\/kde\/svn\/trunk/\$src\$}";; /usr/local/build/kde/svn/trunk/*) printf %s "${PWD/#\/usr\/local\/build\/kde\/svn\/trunk/\$build\$}";; *) printf %s "$PWD";; esac } paul

Re: ${parameter+word} not documented in bash.info or bash(1)

below, word is subject to tilde expansion, parameter expansion, command substitution, and arithmetic expansion. When not performing substring expansion, bash tests for a parameter that is unset or null; omitting the colon results in a test only for a parameter that is unset. paul

Re: Can't execute file from command line

ename. Removing the carriage returns would fix that. The problem is unlikely to be in bash itself, so if the above suggestion doesn't help, you're more likely to find the answer in a forum for Sun Studio than for bash. paul

Re: $(grep anycommand anyfile) fail

full shell-language parsing instead, quote it and use eval: $ eval "$(grep ls test)" paul

Re: command not found on remote server

you want, then it's best to invoke /directory/some-command by its full path. paul

Re: command not found on remote server

meter: ssh [EMAIL PROTECTED] 'export PATH=$PATH:/other path/ ; script param' paul

Re: Possible bug with respect to global variable within block of code when piping the output of later

Thiemo Kellner <[EMAIL PROTECTED]> wrote: > Maybe the piping converts the block implicitly to a subshell. Yes, it does. This is documented in the man page, under "Pipelines" in the "SHELL GRAMMAR" section, and in the FAQ, entry E4. paul

Re: [severe] access outside simlinked directory

ash's. When interpreting pathnames relative to the current working directory, the kernel only cares about where you are, not how you got there. It's been that way for as long as Unix has had symlinks, and changing it now would break a lot of programs that expect the current behavior. paul

Re: Regular experssions are not working in 3.2.39 as in 3.1.17

[EMAIL PROTECTED] wrote: > regular expression are broken in 3.2.39 It's not broken; it's different. See entry E14 in the bash FAQ, and check out the compat31 option in shopt. paul

Re: errexit inconsistent behaviour with pipelines

g - meaning that "true | false" will no longer cause the shell to exit. paul

  1   2   3   >