Re: strange 'delayed' aliases

as causes the command history to report the second line as a separate command: $ alias x='echo Hello, \ > ' $ x $ World! Hello, World! $ history 2 481 x; World! 482 history 2 Hope this helps. - Jonathan

Re: 'test' builtin of bash returns wrong value for '! -a FILE' operation

tags 426990 - moreinfo tags 426990 + upstream # documentation bug severity 426990 minor retitle 426990 bash: "help test" gives no hint of complicated precedence rules quit OZAKI Masanobu wrote: > On Fri, 2010-11-05 at 03:17:13 -0500, Jonathan Nieder > wrote: >>> P

PS1 has ruined line wrap

rewrites the current line if I write text past the current window size (regardless of the window size). filenameERVERNAME:/home/jreed]$ cat /a/really/long_fi Any suggestions? Thanks, Jonathan

Re: PS1 has ruined line wrap

An old thread but I found a way around this by adding a line to my bashrc: echo -ne "\033]0; `whoami` @ `hostname` \007" The reference http://mdinh.wordpress.com/2010/11/21/xterm-title-bar/ On Thu, Nov 25, 2010 at 7:26 PM, Chet Ramey wrote: > On 11/25/10 3:38 PM, Jonathan Reed

Re: PS1 has ruined line wrap

ittle more control in my window manager. But you are correct in saying that my .bashrc workaround is not the proper way to handle my problem since it does not handle a scenario where multiple logouts are performed after a chain of logins. On Mon, Feb 14, 2011 at 9:30 AM, Chet Ramey wrote: >

Re: cd --help should output the complete man page

Hi Faheem, Faheem Mitha wrote: > $ cd --help > bash: cd: --: invalid option > cd: usage: cd [-L|-P] [dir] > > I'm don't even know how to get the usage output without > inducing an error. Does "help cd" do the trick? > I think a man page might also be a good idea. You may > als

Re: bash: $() doesn't preserve new lines

Hi again, Dmitry Baryshev wrote: > 2011/4/14 Jonathan Nieder >> ? Note that 'echo' is an ordinary built-in utility, which will behave >> in most respects like an external utility. So the expansion gets >> passed to it as a sequence of arguments. As "help

Re: bug on [A-Z] and [a-z]

ng the same case" means. If you'd like to work on this, please feel free to coordinate using the aforementioned libc bug report (and cc-ing me). A separate aspect is documentation. I imagine Chet wouldn't mind a patch to bash.1 and bash.info to explain this pitfall under "Pattern Matching" or even under "BUGS" (aka LIMITATIONS). Hope that helps, Jonathan

Re: eval

Hi Rafael, Rafael Fernandez wrote: > set -- a b c d e f g h i j k l m n o p q r s t u v w x y z > i=1 > eval echo '$'$i # outputs an expected 'a' > i=10 > eval echo '$'$i # outputs 'a0'; expected 'j' > i=11 > eval echo '$'$i

Re: eval

Rafael Fernandez wrote: > Thanks, I wasn't aware that positional parameters greater than nine have to > be enclosed in brackets. No prob. The manpage says When a positional parameter consisting of more than a single digit is expanded, it must be enclosed in braces (see E

[PATCH/RFC] bash.1: "shopt -s checkwinsize" has no effect in non-interactive shells

Explain that COLUMNS and LINES are not set automatically in non-interactive shells, and recommend direct use of the tput utility from ncurses as a replacement. Fixes: http://bugs.debian.org/628638 Reported-by: Leslie A Rhorer Helped-by: Leslie A Rhorer --- Hi Chet et al, Here's a quick document

Re: printf treats arguments of "%c" not as expected

ur application. Back to the bug: I don't see any explanation of "printf %c" when I run "man bash". Perhaps your manual is different from mine, but if you, perhaps it would be possible to suggest a few words to explain this for future readers. Thanks and regards, Jonathan [*] http://unix.org/2008edition/

License details for bash-4.2

individual copyright holders but thought I should ask here first in case there is information available that could save the trouble. Thanks and regards, Jonathan

License of bash manpage (Re: License details for bash-4.2)

Hi Chet et al, Jonathan Nieder wrote: [concerning licensing] > Looking over bash 4.2, I have a few questions: After investigating a little more and testing with files removed, I'm down to one question (though it would still be nice to clarify the licenses of the other files mentioned):

Re: License of bash manpage (Re: License details for bash-4.2)

ouch with some of the people who submitted example functions and scripts to find out their wishes. Cheers, Jonathan

Re: License of bash manpage (Re: License details for bash-4.2)

Chet Ramey wrote: > I wrote the entire test suite except for the one file from Glen Fowler. > It is (or should be) copyright GPL3 just like the rest of the distribution. Just wanted to say thanks for the clear and quick responses. They helped. Jonathan

Re: integer addition crash

AQ[*] has some details. Hope that helps, Jonathan [*] http://tiswww.case.edu/php/chet/bash/FAQ question E8 ("Why does the arithmetic evaluation code complain about `08'?")

bash completion

I have a bash completion file (see below) It works fine, but i would like add a feature => not expand the flag by a space when it contain '=' curently when i do: $ ldc2 -Df ldc2 -Df=⊔ i would like: ldc2 -Df ldc2 -Df= without space tanks a lot --- # bash completion for ldc _ldc()

Re: bash completion

Le mardi 09 août 2011 à 10:05 +0800, Clark J. Wang a écrit : > On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER > wrote: > I have a bash completion file (see below) > It works fine, but i would like add a feature => not expand > the flag by >

Re: pwd as first command changes script behavior

5r1/with-camera That's what $_ is advertised to do: it expands to the last argument to the previous command, after expansion (or the full pathname to the shell or shell script if there was no previous command). You're probably looking for $(which $0) or something similar. Hope that helps, Jonathan

Bug: shell history loses lines beginning with # in a here-document

[I've just created a bug report at Savannah, but looking at the Bash page on gnu.org I realised it should have ben sent here rather than ] Run these command: $ gcc -x c - <  int main() { printf("hi\n"); }  EOT $ ./a.out hi now use the up cursor (or "fc -2

Re: Execution strange when get lines of the console in script with command substitution and the rediretion of the stderr.

esumably be welcome. > I don't know why it is. What is amazing is the number 24. That's the traditional height of an 80x24 terminal. Hope that helps. Regards, Jonathan

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

at it without making the manpage much longer (maybe by tweaking the sentence that starts "A restricted shell is used to set up an environment"), I imagine that would be helpful. Thanks and hope that helps, Jonathan

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

Sarnath K - ERS, HCLTech wrote: > Apart from this, BASH Documentation says "When a command that is > found to be a shell script is executed (see COMMAND EXECUTION > above), rbash turns off any restrictions in the shell spawned to > execute the script.". > > Does this mean that a guy with restric

Cross compile crapout

Trying to compile for an arm target I get this execute_cmd.c: In function 'execute_pipeline': execute_cmd.c:2205: error: 'job_control' undeclared (first use in this function) execute_cmd.c:2205: error: (Each undeclared identifier is reported only once execute_cmd.c:2205: error: for each function i

Re: Cross compile crapout

On Sat, 2012-01-21 at 19:45 -0500, Chet Ramey wrote: > On 1/21/12 11:13 AM, Jonathan Andrews wrote: > > > I found the fix here, but it would be nice if it could work its way into > > the source for the next release. > > > > http://lists.gnu.org/archive/html/

Re: Cross compile crapout

On Mon, 2012-01-23 at 20:30 -0500, Chet Ramey wrote: > On 1/23/12 1:12 AM, Jonathan Andrews wrote: > > > I needed a statically linked bash for testing an arm board. I did not > > expect it to be nearly 3MB though ! It surprises me that a statically > > linked bash i

Re: Cross compile crapout

On Tue, 2012-01-24 at 08:09 -0500, Chet Ramey wrote: > On 1/23/12 10:17 PM, Jonathan Andrews wrote: > > > Im not a gcc expect, I thought the idea of the linker was also to drop > > unused code but this seems not to be true with gcc as default. > > Sure, but it's

Re: Bash scripting and large files: input with the read builtin from a redirection gives unexpected result with files larger than 2GB.

hitecture, where _FILE_OFFSET_BITS=64 is the default, anyway. So I fear the problem is somewhere else. (Maybe an "int" is used as an offset somewhere.) Hope that helps, Jonathan

Broken 'test -x' behaviour for euid=0 on Solaris

at() implementation has not diverged between illumos and Solaris 11, but again I do not have access to a Solaris 11 system to verify this for certain. Regards, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com

Re: Broken 'test -x' behaviour for euid=0 on Solaris

* On 2013-02-28 at 19:13 GMT, Chet Ramey wrote: > On 2/28/13 9:24 AM, Jonathan Perkin wrote: > > > There is already handling for this chosen behaviour within sh_eaccess(), so > > it > > is simply a matter of extending it for the faccessat() case, as implemented &g

Re: Bug/limitation in 'time'

on/> for hints. Hope that helps, Jonathan

Re: [bash] wait: specify that you can only wait for child PIDs

is message in mbox format and applying with "git am --scissors".) -- >8 -- Subject: bash.1: processes waited for by "wait" are children Reported-by: Török Edwin --- Thanks, Jonathan [1] http://bugs.debian.org/714743 doc/bash.1 | 2 +- 1 file changed, 1 insertion(+), 1 d

Variable casts from string to array but silently fails in reverse

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE

Re: Variable casts from string to array but silently fails in reverse

Thanks - understandable although was confusing at the time and made for a nasty subtle scripting bug. Bash is not for the faint hearted. On 31 January 2014 19:45, Chet Ramey wrote: > On 1/31/14 10:39 AM, Jonathan Doull wrote: > > > Bash Version: 4.2 > > Patch Level: 25

Re: "[ -n ${emptyvariable} ]" returns success

On 09/20/2007 07:46 PM, Paul Jarc wrote: [EMAIL PROTECTED] wrote: foo= [ -n ${foo} ] && echo true Prints "true". That's the correct behavior. OK, thanks for the explanation. It makes sense, although I think it's just a little gross. ;-) To avoid pitfalls

Command prompt disappears when working directory is one whose name ends in a '\' (backslash)

Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash

strange 'delayed' aliases

lease *$* alias x='echo \ *>* ' *$* x *$* Hello, World! Hello, World! ** Is this delayed response expected? Regards, Jonathan

Re: strange 'delayed' aliases

> > There is certainly unexpected behavior going on here. I'll take a closer > look, but fixes will have to wait until bash-4.2 (or a patch to bash-4.1 > if the problem is widespread). 4.2 would be fine but not before please! I'm still scheming how best put this feature to "good" use in my "frie

Typo in documentation

Hello, On the page http://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html, in the section *${parameter%%word}*, there is a duplicate phrase in the sentence "If the pattern matches If the pattern matches a trailing portion of the expanded value of parameter, then the resu

Shell exits after process substitution when using DEBUG trap with extdebug

$ bash --version GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) $ uname -a Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23 20:21:29 PDT 2020 x86_64 GNU/Linux (This is a Pixelbook running the default Crostini Linux VM under Chrome OS 84.0.4147.110. I can reproduce the

Re: Shell exits after process substitution when using DEBUG trap with extdebug

On Tue, Aug 4, 2020 at 9:20 AM Chet Ramey wrote: > On 8/3/20 9:44 PM, Jonathan Rascher wrote: > > $ bash --version > > GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) > > > > $ uname -a > > Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun

Verifying behavior of nameref feature

{!foo} intended to yield the name of the var that foo references, now that foo has been turned into a nameref? I wanted to use this functionality in a script, but wanted to make sure it was intentional before I rely on it. Thanks, -Jonathan Ha

Re: Interactive job control and looping constructs

If this behavior (ignore with warning one or more Ctrl-Z keypresses during loops before eventually backgrounding) was desirable, there may be code that could be borrowed from IGNOREEOF handling (I haven't looked at it). -Jonathan Hankins On Wed, Dec 31, 2014 at 1:26 PM, Ed Avis wrote: >

Re: [bug-bash] Named fifo's causing hanging bash scripts

quot;$link,$link_dir,$link_dest" done < <(find . -type l -printf '%p|%h|%l\n' 2>/dev/null) -Jonathan Hankins On Fri, Jan 16, 2015 at 9:46 AM, Chet Ramey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 1/16/15 10:32 AM, Dr. Werner Fink wrote: > &

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

with more knowledge than myself might want to look at this closer. It seems like it might be a vector for abuse. -Jonathan Hankins On Fri, Jan 30, 2015 at 9:06 AM, Greg Wooledge wrote: > On Fri, Jan 30, 2015 at 09:58:43AM -0500, Chet Ramey wrote: > > On 1/30/15 4:36 AM, crocket wrote

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

I can get some time, I will play around with it over the weekend and see if I can confirm my suspicions. -Jonathan Hankins On Fri, Jan 30, 2015 at 1:25 PM, Chet Ramey wrote: > On 1/30/15 2:09 PM, Jonathan Hankins wrote: > > A test with the POSIX S_ISREG macro on HISTFILE will determine i

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

e non-regular files. I also think the handling of the case where HISTFILE is a symlink may misbehave (it would read the history in from the file the link refers to, but on overwrite, replace the symlink, instead of the file it refers to.) -Jonathan Hankins On Fri, Jan 30, 2015 at 3:27 PM, Andreas S

Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

On Sat, Jan 31, 2015 at 4:40 PM, Chet Ramey wrote: > On 1/30/15 3:50 PM, Jonathan Hankins wrote: > > I agree about being able to use named pipes, etc. as HISTFILE. My > concern > > is that I think there may be a code path that leads to rename() and > > open(O_TRUNC...) b

Re: Does [ -f FILE ] have a bug on testing a symlink ?

$ touch foo $ ln -s foo bar $ [[ -f foo ]] && [[ ! -h foo ]] && echo "exists and is not a symlink" exists and is not a symlink $ [[ -f bar ]] && [[ ! -h bar ]] && echo "exists and is not a symlink" $ -Jonathan Hankins On Mon, Feb 9, 2015 at 6:

Re: Does [ -f FILE ] have a bug on testing a symlink ?

a symbolic link, test shall evaluate the expression by resolving the symbolic link and using the file referenced by the link." -Jonathan Hankins On Tue, Feb 10, 2015 at 3:25 PM, Stephane Chazelas < stephane.chaze...@gmail.com> wrote: > 2015-02-09 14:59:06 -0700, Bob Proulx: > [..

dead link

Hi there There is a dead link in the online bash manual for shopt: http://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html [promptvars] "Controlling the Prompt" should point to http://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt It currently points to h

Re: Feature Request re: syslog and bashhist

Maybe OT, but there is software to hook exec at the system library level and provide syslog auditing: https://github.com/renard/snoopylogger -Jonathan Hankins On Thu, Sep 3, 2015 at 2:43 PM, Chet Ramey wrote: > On 9/3/15 2:43 AM, Ondrej Oprala wrote: > > > We have recently ha

Double slash root cwd

Hey there- Noticed in bash you can cd into paths prefixed with double slash; e.g. “cd //usr/sbin” and it will set the pwd environment variable as such; not sure if this was intended or not, but can see where some poor guy’s aliases or bash scripts are likely to barf. Jonathan

Re: Double slash root cwd

Cool... thanks! Pardon teh spellnig; Sent form my iPhone > On Dec 11, 2016, at 4:55 PM, Chet Ramey wrote: > >> On 12/11/16 4:10 PM, Jonathan Ździarski wrote: >> Hey there- >> >> Noticed in bash you can cd into paths prefixed with double slash; e.g. “cd >>

Re: history vs. poweroff

This is discussed a bit here, along with a common pain point for tmux/screen users: https://news.ycombinator.com/item?id=10164053 zsh gets around both issues with a variety of options to have a synchronous and interleaved history file. -Jonathan Hankins On Tue, Jan 31, 2017 at 1:40 PM Greg