[Suggestion] Flush command history to a "backup" file periodically
Currently, in the event bash or something below it crashes, that session's command history is lost. It would be nice if bash saved it somewhere periodically, it doesn't have to be too often, let's say on every second command. That way, history could be restored from the "backup" file when the shell starts after a crash, for example. Let me know what you think. Thank you.
Du wirst ausspioniert ....!
und weisst es nicht einmal: http://www.heise.de/newsticker/meldung/58003 http://www.heise.de/newsticker/meldung/59304 http://www.heise.de/newsticker/meldung/58311 http://www.heise.de/newsticker/meldung/58351 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
crash in __waitpid() via waitchld() in bash 4.4.23(1) on arm64
Hello, I've had a crash in bash 4.4.23(1) running on arm64 with glibc 2.28. This is a custom distro based off the yocto thud release. I've only seen this twice in the last 6 months or so and thus is not easy to recreate. Stacktrace looks like this: #0 libc_2_28!__waitpid + 0x30 #1 bash!waitchld + 0x10c #2 bash!wait_for + 0x568 #3 bash!execute_command_internal + 0x2718 #4 bash!execute_commnad + 0x60 #5 bash!reader_loop + 0x188 #6 bash!main + 0xfe0 #7 libc_2_28!__libc_start_main + 0xe4 #8 bash!start + 0x34 I have a bash script which is executing a long running process: ``` #!/bin/bash ./longrunningthing echo "done!" ``` The above crash was seen when systemd sent "longrunningproces" a SIGTERM. "longrunningprocess" is multithreaded, and handles SIGTERM via a signal handler then exits. In the normal case I don't see the crash and the script exits successfully. Does this ring any bells to anyone? Is there any other information that would be useful to help me debug this further? Thanks, Peter.
Re: libtool 2.4 args parsing incredibly slow
Hi,
Dan reported a libtool performance regression in libtool-2.4 when
running his binaries with a large number of arguments.
Libtool creates a shell script which usually sets some env vars and runs
the binary, new in recent libtool, the script also takes arguments, so
these have to be removed when execing the binary.
Because forking is usually quite expensive, this shell function avoids
forks:
func_exec_program ()
{
for lt_wr_arg
do
case \$lt_wr_arg in
--lt-*) ;;
*) set x "$@" "$lt_wr_arg"; shift;;
esac
shift
done
func_exec_program_core ${1+"$@"}
}
Turns out that bash is relatively slow here, even with a simpler loop:
for arg
do
echo "$@" >/dev/null
done
$ time bash ./s.sh `seq 1 1000`
real0m9.866s
user0m8.104s
sys 0m0.088s
$ time dash ./s.sh `seq 1 1000`
real0m0.571s
user0m0.355s
sys 0m0.097s
$ time zsh ./s.sh `seq 1 1000`
real0m0.770s
user0m0.541s
sys 0m0.079s
I have not investigated what the other shells are not doing that bash is
doing here, it's entirely possible that they're buggy in some way that
bash isn't.
We'll try to fix libtool to not cause this problem too, of course.
Thanks,
Peter
Brace expansion inside of command substitution - broken or is it me?
Hi all,
I stumbled upon some rather strange behaviour that I just can't explain.
Hopefully one of you can help me with that. :)
Let's start with a simple brace expansion:
$ echo {1..3}
1 2 3
Now add some quotes to prevent that expansion:
$ echo "{1..3}"
{1..3}
Adding command substitution:
$ echo $(echo "${1..3}")
{1..3}
So far, so good. It's what I expected. Let's add another level of
quotes:
$ echo "$(echo "{1..3}")"
1 2 3
Huh? Actually, I was expecting to get the same output as before.
Some debug output:
$ set -x
$ echo "$(echo "{1..3}")"
++ echo 1
++ echo 2
++ echo 3
+ echo 1 2 3
1 2 3
Why's that?
a) As far as I understood, quotes inside of $(...) should not interfere
with the outer quotes.
b) Why are there three subshells? Actually, that {1..3} doesn't get
expanded. It's more like the call above is effectively equivalent to
this:
$ echo "$(echo 1)" "$(echo 2)" "$(echo 3)"
To sum up my question: Why do I get
$ echo "$(echo "{1..3}")"
1 2 3
instead of
$ echo "$(echo "{1..3}")"
{1..3}
?
I saw this happening on every version of Bash I could find -- ranging
from Bash 4 in current Arch Linux to some old Bash 3 of msysgit[1] on
Windows. Tried it on the last two or three versions of Ubuntu. And so
on. To be honest, this almost convinces that I really missed something,
so any help is very much appreciated.
Below[2] is the information about my current system (Arch Linux) that
"bashbug" gave me.
Many thanks in advance,
Peter
[1] http://code.google.com/p/msysgit/
[2] bashbug-infos:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2
-pipe
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin'
-DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin'
-DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux pinguin 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 11 16:55:18 UTC
2011 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.1
Patch Level: 9
Release Status: release
Re: Brace expansion inside of command substitution - broken or is it me?
Hi,
On Fri, Feb 18, 2011 at 07:26:18PM -0500, Chet Ramey wrote:
> Brace expansion is strictly textual, is performed before all other
> expansions, and doesn't understand a whole lot of shell syntax.
> It does understand a little about quoted strings, so what you get is
>
> echo "$(echo "1")" "$(echo "2")" "$(echo "3")"
>
> The preamble is "$(echo ", the portion to be expanded is {1..3}, and the
> postscript is ")".
thank you for clearing that up!
Aha, I see. I've read that part about "strictly textual" and "performed
before all other expansions" in the manual, but I didn't realize all the
consequences. This means that my quotes get interpreted *after* the
brace expansion is done, right? As a result, a call like
echo "$(echo "{1..3}')'
ends up as
echo "$(echo "1')' "$(echo "2')' "$(echo "3')'
and that surely won't work.
This makes a lot more sense now.
Thanks again,
Peter
path completion with cd - similar to tcsh
Hi all I have been using tcsh for a long time on Red Hat Linux boxes, and bash on other UNIX-boxes. One thing I really love with tcsh is the way I can swiftly operate using the to do auto-complete, when having a deep directory hierarchy. I have that... With bash I surely could use your skills to improve my usage of bash (read; allow me to ditch tcsh fully). I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move to a subdirectory of another directory (e.g. $HOME), where the tab-expand works poorly; Assume $HOME=/home/pto "cd $HOME" is expanded to "cd /home/pto " (without the quotes). I get $HOME expanded - quite ok - but I get an annoying space efter the path. I will never like that space, I strongly prefer if I could get "cd $HOME" expanded to "cd /home/pto/" (without the quotes) so I could continue to press and see the allowed sub-directories - much faster for me. I have also understood I can do $ complete -o nospace cd to change the mode of operation, but this seems to disable the auto-complete function when doing cd $VARIABLE. I am guestimating, that you have discussed this in February (cf. http://www.gossamer-threads.com/lists/gentoo/user/227574) but the February archive seems to be lost; http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html so I cannot get the details of it. That cited link is suggesting; "ESC ctrl-e gets rid of the backslash, and if you want to keep the $VAR as $VAR, backspace over the terminal space and continue. Or you can ESC ctrl-e again, and convert the $VAR to its value, so you won't need to repeat the single ESC ctrl-e for each further ." which IMHO is not really what I want. Any hints on this? Can I set the mode of operation as I like where the infamous space is replaced by a slash when doing "cd ... "? Best -- Peter Toft, PhD http://petertoft.dk
Re: path completion with cd - similar to tcsh
On Fri, 15 Apr 2011 15:07:16 +0800, Clark J. Wang wrote: On Fri, Apr 15, 2011 at 6:19 AM, Peter Toft wrote: Hi all I have been using tcsh for a long time on Red Hat Linux boxes, and bash on other UNIX-boxes. One thing I really love with tcsh is the way I can swiftly operate using the to do auto-complete, when having a deep directory hierarchy. I have that... With bash I surely could use your skills to improve my usage of bash (read; allow me to ditch tcsh fully). I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move to a subdirectory of another directory (e.g. $HOME), where the tab-expand works poorly; Assume $HOME=/home/pto "cd $HOME" is expanded to "cd /home/pto " (without the quotes). I get $HOME expanded - quite ok - but I get an annoying space efter the path. I will never like that space, I strongly prefer if I could get "cd $HOME" expanded to "cd /home/pto/" (without the quotes) so I could continue to press and see the allowed sub-directories - much faster for me. I have also understood I can do $ complete -o nospace cd to change the mode of operation, but this seems to disable the auto-complete function when doing cd $VARIABLE. I am guestimating, that you have discussed this in February (cf. http://www.gossamer-threads.com/lists/gentoo/user/227574) but the February archive seems to be lost; http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html so I cannot get the details of it. That cited link is suggesting; "ESC ctrl-e gets rid of the backslash, and if you want to keep the $VAR as $VAR, backspace over the terminal space and continue. Or you can ESC ctrl-e again, and convert the $VAR to its value, so you won't need to repeat the single ESC ctrl-e for each further ." which IMHO is not really what I want. Any hints on this? Can I set the mode of operation as I like where the infamous space is replaced by a slash when doing "cd ... "? Best -- Peter Toft, PhD http://petertoft.dk That also annoys me much. Try like this: $ complete -o default -o nospace -d cd $ cd $VAR/ well - with this I have to add the slash before the $VAR is expanded. So - not quite there yet[1]. Best Peter [1] who is lazy :) -- Peter Toft, PhD http://petertoft.dk
Re: path completion with cd - similar to tcsh
On Mon, 18 Apr 2011 20:12:24 -0400, Chet Ramey wrote: On 4/14/11 6:19 PM, Peter Toft wrote: I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move to a subdirectory of another directory (e.g. $HOME), where the tab-expand works poorly; Assume $HOME=/home/pto You should see whether or not you have a completion already defined by running `complete -p cd'. It would also help to know the version of bash you're using. That will help establish a baseline. (And RHL 5.x? That's pretty old.) Right! bash --version gives -> 3.2.25(1)-release (x86_64-redhat-linux-gnu) RH5.6 is not cutting edge (but I need it for tools-reasons), but I also dislike the current working method on e.g. Ubuntu 10.10, so I really like to get into the dirt on this one :) $ complete -p cd bash: complete: cd: no completion specification "cd $HOME" is expanded to "cd /home/pto " (without the quotes). I get $HOME expanded - quite ok - but I get an annoying space efter the path. I will never like that space, I strongly prefer if I could get "cd $HOME" expanded to "cd /home/pto/" (without the quotes) so I could continue to press and see the allowed sub-directories - much faster for me. I have also understood I can do $ complete -o nospace cd to change the mode of operation, but this seems to disable the auto-complete function when doing cd $VARIABLE. You need to add -o bashdefault to restore the bash default completions, which include shell variable completion. oki, but "complete -o bashdefault -o nospace cd" will give me tab complete on the possible environment variables, e.g. $ cd $HOME shows "$HOME", which is nice, but I prefer the expanding, and $ cd $HOME/ does nothing (with the -o bashdefault) Any hints on this? Can I set the mode of operation as I like where the infamous space is replaced by a slash when doing "cd ... "? Right now, you cannot do this using only the built-in bash completion mechanisms. The best you can do is to suppress the space. You can write a function to do this, though, and bind it using complete -F funcname cd. That would be really nice, hints to do so would be very welcomed! You can't prevent the `$' from being backslash-quoted and still quote other filenames containing shell meta-characters unless you use a shell function. Chet Thanx Chet for your efforts. BTW; Anyone who has the february emails from this list; "I am guestimating, that you have discussed this in February (cf. http://www.gossamer-threads.com/lists/gentoo/user/227574) but the February archive seems to be lost; http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html so I cannot get the details of it." Anyone who can forward the february-emails? Best Peter -- Peter Toft, PhD http://petertoft.dk
Re: bash tab variable expansion question?
Hi Chet, On Fri, Sep 2, 2011 at 9:32 PM, Chet Ramey wrote: > The attached patch adds a new shell option that, when enabled, is > intended to restore the bash-4.1 behavior of expanding directory names > in filenames being completed. I have done some testing, and it seems > to work the way I intend. This, or some later version, will be part > of the next bash release. I am soliciting feedback on this iteration. the users here are happy with this patch, looking forward to see it in the next release. Peter
incompatibility in regex
Hi, have experienced the following: 3.1.17(1)-release: -> [[ a =~ a|b ]] && echo true -bash: syntax error in conditional expression: unexpected token `|' -> [[ a =~ a\|b ]] && echo true # that one works in version 3 true === 4.1.10(4)-release: -> [[ a =~ a\|b ]] && echo true # ... but not in version 4 -> [[ a =~ a|b ]] && echo true true Do I really need to check BASH_VERSION first? Thanks & regards, Peter
crash bug report, plus complaint about bashbug
Dear bash guys,
Bashbug interface was COMPLETELY useless. The emacs quit key didn't
work. There were no instructions. It didn't even tell me it was emacs so
I could go look it up. I had to find that out elsewhere. Eventually it
wouldn't even let me edit, saying the buffer is read only. What the hell
were you thinking? Why not use the EDITOR variable? That's what it's
for! Not everyone knows how to use every editor.
So here is an email instead, with copy & paste from what I wrote in that
thing before getting annoyed and using "kill -9".
From: peter
To: bug-bash@gnu.org
Subject: [50 character or so descriptive subject here (for reference)]
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKA\
GE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -g -D_GNU\
_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra
-Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable
-Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-us\
e
uname output: Linux peter 3.1.9-1.4-desktop #1 SMP PREEMPT Fri Jan 27
08:55:10 UTC 2012 (efb5ff4) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
Running the following script crashes bash with exit code 141. The
problem occurs on this openSuSE machine, and on FreeBSD with bash
4.1.10, and on Ubuntu with bash 4.1.5.
Repeat-By: (2 line script, this email thing split it in 3)
foo() { while IFS='' read -r line; do echo "$(date) $line" >>
file.txt; done; };
exec 2> >(foo)
Error in read implementation and/or documentation
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 before the delimiter Exit Status: The return code is zero, unless end-of-file is encountered, read times out, or an invalid file descriptor is supplied as the argument to -u. If read is invoked with the -n or -N options, then given an EOF, it returns with a zero exit status. In addition, if it is invoked with -n 3, for example, then given EOF for one of the first 2 characters, it still waits for all 3 characters. I am running the most recent Arch (up to date as of 7/26/13) on a 64-bit machine. Arch package version: 4.2.045-4 $BASH_VERSION: 4.2.45(2)-release Is it possible that this can be fixed? Any suggestions for a work-around if it can't? Peter Olson
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, 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 given EOF for one of the first 2 characters, it still waits for all 3 characters. Cannot reproduce. $ printf 01 | read -n3 $ echo $? 1 Best, Chris
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 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 only `recognized' as EOF when ICANON is set and the ^D is typed as the only character on a line. Chet
savannah.gnu.org bug tracker unused?
(I'll send another email for the bug I found, instead of having 2
topics in 1 thread).
Does anyone look at the bug tracker on Savannah?
https://savannah.gnu.org/support/?group=bash
I submitted a bug there, after going to the GNU project page for bash
http://www.gnu.org/software/bash/ and following the link to the
Savannah page (https://savannah.gnu.org/projects/bash/). I now
realize that nobody has ever closed any of the bugs there, even some
obvious candidates for CLOSE WONTFIX.
I did notice that Chet has replied to one a couple of these bugs, but
didn't close any of them as invalid or wontfix. So I assume the bug
tracker isn't really used.
There have been some closed tickets on the patches page, so I guess
someone looked at that page at least at some point.
https://savannah.gnu.org/patch/?group=bash
I was going through some bugs looking for ones I could help triage,
and found several that aren't actually bugs. I commented on them to
explain why they weren't bugs or weren't necessary features,
summarizing here. Hopefully this is of some use, if anyone decides to
go an look over the savannah bug page.
https://savannah.gnu.org/support/index.php?108381
CLOSE INVALID: POSIX says arithmetic is done with signed integers, so
no, right shift is arithmetic (sign-extending) not logical, unfortunately.
https://savannah.gnu.org/support/index.php?108163
probably invalid, pasting giant buffers into bash loses characters
because of lack of pseudo tty flow control, not bash's fault.
https://savannah.gnu.org/support/index.php?108103
CLOSE WONTFIX: md5 checking of possibly-updated-from-dropbox stuff
can easily be done with wrapper scripts. (This one has a comment from
someone other than the submitter, a guy that says he "really wants to
help with some code", hopefully Jonathan Ganade found his way to a
mailing list or otherwise found something to hack on.)
https://savannah.gnu.org/support/index.php?107974
CLOSE WONTFIX, unless maybe you really really want to be able to do
foo {$n..$m}"$tail" without needing an eval. Or to avoid having to
bust out for (( i=n ; i<=m ; i+=k )) syntax.
https://savannah.gnu.org/support/index.php?105519
CLOSE DONE: feature request for shopt -s autocd
https://savannah.gnu.org/support/index.php?102985
CLOSE INVALID: contrary to the submitter's expectation, POSIX says
printf %c takes a string, not a number. There are pure-bash
implementations of chr and ord (to use the perl names) on
http://mywiki.wooledge.org/BashFAQ/071. (Kudos Greg Wooledge for very
excellent stuff.) Given that, any new features to help with this are
probably not needed. The only odd thing I found while playing around
with this is that printf %c only prints the first byte of the UTF-8
representation of a multi-byte character. (POSIX says to be
"extremely cautious" about using %c with wide characters, apparently
for good reason.)
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cor , des.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
job-control warning message that maybe shouldn't be printed
I submitted this on savannah a couple days ago: https://savannah.gnu.org/support/?108450 As I said there, the warning message for bash re-using a PID that it's tracking for exitted processes in suspended pipelines or w/e has an off-by-one error (jobs.c:892). To summarize what I wrote on savannah: The real question is whether there's any point in printing this warning, or in continuing to track the PIDs of processes that have long since exitted. (in a foo | grep | less, suspend less use case, you have bash remembering the PID for foo and grep, even after they exit). And bash prints a warning if you happen to run a command that re-uses one of those PIDs. I don't see how this is of any use. It just confused my dad, and me until I found the source code that printed it. Thanks for making such a nice shell, this is probably the first time I've had it do something weird that wasn't my fault. Oh, also, the online bug-bash archive has a bad habbit of replacing code with address@hidden. There was a whole thread about setting PS1=whatever that is now a complete mystery to non-subscribers! -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
Re: job-control warning message that maybe shouldn't be printed
On Thu, Nov 28, 2013 at 12:40:34PM -0500, Chet Ramey wrote: > On 11/28/13, 7:23 AM, Peter Cordes wrote: > > I submitted this on savannah a couple days ago: > > https://savannah.gnu.org/support/?108450 > > > > As I said there, the warning message for bash re-using a PID that > > it's tracking for exitted processes in suspended pipelines or w/e has > > an off-by-one error (jobs.c:892). > > Thanks for the report. The message is just informational and designed > to reveal the cases in which this happens. I have to say that I didn't > expect anyone to leave a multi-process pipeline suspended for a week > and trigger it. Yeah, I was surprised how many old glimpse | egrep | egrep | less searches on his genealogy files my dad has suspended, too. And he thinks my mom is weird for leaving a ton of firefox tabs open. :P Part of what I was trying to say is that it wasn't clear from the message itself that it was just informational, and not a sign of some kind of error. (like the machine developing bad RAM, leading to failed sanity checks in processes, who knows?) So maybe a wording change would be in order. Maybe using terms that make sense to people that aren't thinking about bash internals. e.g. "note: PID %d of exitted process in job %d was reused\n" Debating between "note", and "debug", and IDK what else would be good. The big confusion for my dad was that none of the suspended jobs were "running", they were all suspended. (as opposed to bg'ed.) He's been using Unix and Linux for something like 20 years now, a few more than me, a but mostly just as a user, not so much sysadmin or systems programming. So I think we can take his reaction as that of an experienced but non-hacker user, if that helps. Probably very few people ever see this message, so I'm probably overthinking this. Still, while you're fixing the off-by-one, might want to update the wording if you like my suggestion. > The original motivation for the message was to figure out > how big the pid-reuse problem was after a discussion started by > > http://lists.gnu.org/archive/html/bug-bash/2012-07/msg00054.html > > That's where you see the Posix requirement that shells save the exit > status of the last CHILD_MAX processes. Ah. Thanks for the background on why this message was there in the first place. I guessed there must have been something that someone was worried about or was trying to debug, in a very different use-case from mine. > Bash does the right thing; it zeroes out the saved pid information. Indeed, I noticed the code to do that had worked correctly, looking at jobs -l. (That's also how I was sure there was an off-by-one, since the zeroed PID was in job 23, not 22.) If saving PIDs of exitted processes in suspended pipelines is required, then the only decision left is what the warning message should be when it has to zero out one of them, if any. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: why are \d and \D not implemented but don't throw errors in regex?
On Sat, Dec 07, 2013 at 11:06:22AM -0600, Craig Steffen wrote: > Hi, > > I'm working on some bash scripts for work where I'm using a regular > expression to grab a number from the output of another command. > > I've gotten fairly adept at using regular expressions, in perl mostly, > but I just couldn't get it to work in bash. > > One reason was that the regex search is supposed to be a variable > rather than an literal inside the [[ ]] expression. > > However, the second reason was that \d and \D are apparently not > implemented, even though \s and \S are? And furthermore, the match > just silently fails without indicating anything is amiss. After > searching, [[:digit:]] does work instead of \d. That's the behaviour of the regex library used by most things other than perl (which has its own regex engine). e.g. search a man page with less(1), \s matches whitespace, \d matches the letter d. [[:digit:]] matches digits. I agree your complaint seems valid, but it's the behaviour of the regex engine built into GNU libc (in this case). Bash on other platforms would use the regex engine in their system libc. (Unless I'm mistaken in my assumption that bash doesn't have its own regex engine.) It's really unfortunate that there are so many not-universally-supported extensions to the regex language. And as you discovered, especially unfortunate that implementations that don't support them just treat them as \-quoted literals, rather than unsupported syntax. There are probably things that depend on using \something even when "something" isn't a special character. However, POSIX says The interpretation of an ordinary character preceded by a backslash ( '\' ) is undefined. http://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap09.html So anything that broke with a regex library that didn't just treat \something as literal something would be the fault of whatever was depending on that behaviour. So it would probably actually be good if the default behaviour of glibc was to report a regex compilation error in that case, or maybe even better, print a warning like "\d: unknown special character, treating as literal". Of course, POSIX doesn't specify either \s or \d, just the [:space:] and [:digit] and other character classes that can be used within []. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
problem with loading /etc/profile
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandriva-linux-gnu'
-DCONF_VENDOR='mandriva' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include
-I../lib -D_GNU_SOURCE -O2 -fomit-frame-pointer -pipe -march=i586
-mtune=pentiumpro
uname output: Linux deepblue 2.6.12-12mdksmp #1 SMP Fri Sep 9 17:43:23
CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz unknown GNU/Linux
Machine Type: i586-mandriva-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
Hello,
I have problem with my bash. He doesn't read my
/etc/profile, /etc/bashrc, ~/.bash_profile and ~/.bashrc
under root work's everything ok
all users are allowed to read /etc/profile
and in /etc/passwd is /bin/bash for all user .. included root
do you have any idea how solve this problem?
thanks
peter guspan
Repeat-By:
I tried something like :
# cp /bin/sh /home/user/getroot
# chmod a+s /home/user/getroot
$ ./getroot
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
How to use [[ string =~ regexp ]]?
Hello. Please CC my email to answers as I'm not subscribed to the list. I have problems using =~ operator. I've tried to search for answer, but failed. I'm using GNU bash, version 3.1.17. Can anybody give me some examples of usage? I really do not understand why $ [[ "string" =~ "[a-z]" ]] && echo something something echo me something. IIUC the regular expression [a-z] matches any single letter, so how string "string" matches one letter? Seems that I missed the point, or did I encounter bug? Thank you for any help, Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to use [[ string =~ regexp ]]?
On Вск, 2006-05-21 at 15:55 -0400, Paul Jarc wrote: > [a-z] matches only one charater, but the pattern is not required to > match against the entire string. On Вск, 2006-05-21 at 13:57 -0600, Mike Stroyan wrote: > The =~ regexp match will match a substring by default. You can use ^ and $ > to anchor the expression to the start and end of the string. Yes! That was what I missed. On Вск, 2006-05-21 at 22:40 -0400, Chet Ramey wrote: > It seems reasonable that quoting any part of the rhs to the =~ > operator should cause it to behave in the same manner. > > Since the arguments to [[ don't undergo any of the expansions that > require quoting to protect them, there's no reason for =~ to act > differently than the other operators that do pattern matching. Never noticed that. This is really interesting. Thank you all for your answers, Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash 3.1.x doesn't close linux fifos properly. See gentoo bug 133635.
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=athlon-xp -mmmx -msse -mfpmath=sse -m3dnow -O3 -pipe -fomit-frame-pointer uname output: Linux cool 2.6.16-gentoo-r6 #1 PREEMPT Sat May 6 22:46:53 BST 2006 i686 AMD Sempron(tm) Processor 2800+ GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Bash 3.1.16 doesn't seem to close named pipes properly. I've reported this on the gentoo bugs list as bug 133635. The version reported above is ok. Repeat-By: Test script: #!/bin/bash myfifo=/tmp/pipetest-fifo-$$ rm -f $myfifo mkfifo $myfifo cat <$myfifo & catpid=$! exec 55>$myfifo echo "Fred" >&55 echo "woz" >&55 echo "ere" >&55 exec 55>&- wait $catpid Running the test script in bash 3.1.16 hangs after printing "ere". Bash 2.05x and 3.0.x terminate normally. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: logout from interactive subshell
"Com MN PG P E B Consultant 3" wrote:
>rlogin foobar
>DO SOME STUFF
>cleartool setview myview # this creates a subshell
>DO MORE STUFF
>cleartool setview yourview # now I'm two subshells deep
>DO STILL MORE STUFF
># Now I want to exit
>exit
>exit
>logout
You can turn cleartool into a function that exits the shell after
running the real cleartool.
cleartool() { command cleartool "$@"; exit; }
Works in both shells.
--
Peter Stephenson <[EMAIL PROTECTED]> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
To access the latest news from CSR copy this link into a web browser:
http://www.csr.com/email_sig.php
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bush-3.2 regression: breaked colour prompt.
Hello. I use the following colored primary prompt string: PS1="\[\033[01;32m\]\w \$\[\033[00;00m\] " Then I create directory with russian name. (locale ru_RU.UTF8). If I cd into directory in bash-3.1 everything works as expected but in bash-3.2 cursor became positioned N spaces after $ and every typed character depart the previous the same N spaces. Well better to illustrate: In bash-3.1: ~/tmp/bash/bash-3.1 $ mkdir тест ~/tmp/bash/bash-3.1 $ cd тест/ ~/tmp/bash/bash-3.1/тест $ ls ~/tmp/bash/bash-3.1/тест $ # In bash-3.2: ~/tmp/bash/bash-3.2 $ mkdir тест/ ~/tmp/bash/bash-3.2 $ cd тест/ ~/tmp/bash/bash-3.2/тест $ ls ~/tmp/bash/bash-3.2/тест $ # Where # denotes cursor position. You see that 'l' and 's' are separted with 8 spaces and initial cursor position also separated from $ on 8 spaces. BTW. With PS1="\w \$ " everything works but there is no color :) JFYI: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/home/peter/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb 11 19:07:33 MSK 2007 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 0 Release Status: release And please CC me to answers. Thank you. Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 regression: breaked colour prompt.
Hello Chet. On Fri, 2007-02-23 at 16:43 -0500, Chet Ramey wrote: > I can't reproduce this on Mac OS X, using Terminal or xterm. I will > look further when I have access to a Linux machine. I've checked this behavior and in xterm everything works. Thus seems that this is konsole bug and bash works as it should. Thank you for your answer. Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 regression: breaked colour prompt.
On Сбт, 2007-02-24 at 09:37 +0100, Andreas Schwab wrote: > Volkov Peter <[EMAIL PROTECTED]> writes: > > I've checked this behavior and in xterm everything works. Thus seems > > that this is konsole bug and bash works as it should. > > Except that is also fails in xterm, or any other terminal. Hm... Right. It's broken in xterm also. I overlooked something during previous testing in xterm. Sorry for the noise. Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Another bash-3.2 regression: coloured prompt confuses Ctrl+R.
Hello. The issue was reported at http://bugs.gentoo.org/156292 and is still reproducible in bash-3.2 patch level 10 and with redisplay-cursor-patch. To save you time steps to reproduce the problem: 1. Set PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] ' 2. cd /usr/share 3. press +R, then press letter 'e' and press button. Cursor appears at the first position in the line (the most left column). This is reported to work as it should in bash-3.1 patch level 17. Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -mtune=pentium-m -fomit-frame-pointer -mcpu=pentium-m -pipe uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb 11 19:07:33 MSK 2007 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 10 Release Status: release Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.2 regression: command history display with coloured PS1.
Hello. The following bug (http://bugs.gentoo.org/172260) == Steps to reproduce: PS1="\e[36m[\e[34m\u\e[0m \e[32m\w\e[36m] \\$\e[0m " LC_ALL="en_US.UTF8" ls echo ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Bash 3.1.* works correctly. == is reproducible with patch Chet provided in thread "bash-3.2 regression: broken colour prompt". So i think this is another bug. Thank you in advance. -- Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 regression: command history display with coloured PS1.
On Пнд, 2007-03-26 at 17:35 +0200, Andreas Schwab wrote: > Peter Volkov <[EMAIL PROTECTED]> writes: > > Steps to reproduce: > > PS1="\e[36m[\e[34m\u\e[0m \e[32m\w\e[36m] \\$\e[0m " > > This is broken. You need to bracket escape sequences with \[ \]. Eh. Right. Sorry for noise. -- Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
VPATH build fails to install bash.info (all Versions 3.x) + patch
Hi,
a VPATH build of bash-3.2 fails to install bash.info because doc/Makefile.in
assumes that bash.info is in the source tree, whereas it is in fact in the
build tree. The attached patch (inspired by automake) covers both
possibilities.
The second small patch is needed for the builtins manpage (at least with
some man systems).
regards
Peter Breitenlohner <[EMAIL PROTECTED]>A VPATH build fails to install bash.info (in Versions 3.x this
file is in the build tree, not in the source tree!).
The patch (inspired by automake) covers both possibilities.
diff -ur bash-3.2.orig/doc/Makefile.in bash-3.2/doc/Makefile.in
--- bash-3.2.orig/doc/Makefile.in 2004-07-27 14:57:48.0 +0200
+++ bash-3.2/doc/Makefile.in2007-03-28 22:22:04.0 +0200
@@ -225,7 +225,8 @@
-$(INSTALL_DATA) $(srcdir)/bashbug.1
$(DESTDIR)$(man1dir)/bashbug${man1ext}
# uncomment the next line to install the builtins man page
# -$(INSTALL_DATA) $(srcdir)/builtins.1
$(DESTDIR)$(man1dir)/bash_builtins${man1ext}
- -$(INSTALL_DATA) $(srcdir)/bash.info $(DESTDIR)$(infodir)/bash.info
+ -if test -f bash.info; then d=.; else d=$(srcdir); fi; \
+ $(INSTALL_DATA) $$d/bash.info $(DESTDIR)$(infodir)/bash.info
# run install-info if it is present to update the info directory
if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \
install-info --dir-file=$(DESTDIR)$(infodir)/dir
$(DESTDIR)$(infodir)/bash.info; \
diff -ur bash-3.2.orig/doc/builtins.1 bash-3.2/doc/builtins.1
--- bash-3.2.orig/doc/builtins.12004-05-24 16:19:55.0 +0200
+++ bash-3.2/doc/builtins.1 2007-03-28 22:20:48.0 +0200
@@ -10,6 +10,6 @@
ulimit, umask, unalias, unset, wait \- bash built-in commands, see
\fBbash\fR(1)
.SH BASH BUILTIN COMMANDS
.nr zZ 1
-.so bash.1
+.so man1/bash.1
.SH SEE ALSO
bash(1), sh(1)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Multibyte characters in prompt still confuse Ctrl+R.
Hello. Another bug report was filled in in our bugzilla: http://bugs.gentoo.org/177095 bash-3.2 patch level 17. If PS1 contains multibyte characters this confuses readline during update_line. To reproduce set PS1='абвгдежзиклмноп ' and then press Ctrl+R. I've debuged problem a bit and although I'm not sure how to fix I'll report my observations. gdb shows that update_line() is called with the following arguments: update_line (old=0x812a558 "абвгдежзиклмноп ", new=0x8124628 "(reverse-i-search)`': ", current_line=0, omax=31, nmax=22, inv_botlin=0)at display.c:1220 when program gets display.c:1517 col_lendiff=6 >0 and lendiff=-9. And this negative value is passed to 1534: insert_some_chars (nfd, lendiff, col_lendiff); which leads to output corruption. Or in English this bug is reproducible when difference in characters (length on the screen) for new and old buffers is positive but difference in number of bytes is negative. To successfully reproduce bug PS1 (in bytes) should be longer then 22 (the length of '(reverse-i-search)`': '). Note that this is also reproducible if PS1 contains \W or \w and directory name is multibyte with the above mentioned conditions. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash manpage problems + patch
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash-3.2 -I../bash-3.2/include -I../bash-3.2/lib
-O2
uname output: Linux pcl321 2.6.20-i686 #3 SMP Fri Mar 23 15:31:48 CET 2007 i686
GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
(1) The bash.1 manpage suffers from a rather ugly formatting problem
due to a typo.
(2) I like the bash_builtins.1 manpage, which is, however, not installed
by the distributed Makefile.in. Unfortunately that manpage cannot be
displayed by all man browsers (man-db and possibly others as well).
Whereas AFAIK all man browsers understand ".so man1/bash.1" only some of
them understand ".so bash.1".
(3) It would be nice if the bash_builtins.1 manpage could be installed
without modifying Makefile.in (and without doing it manually), e.g., via
a configure option or a make variable specified on the make command
line.
Repeat-By:
(1) Say "man bash" and search for the paragraph starting with
"${parameter/pattern/string}" in the section "Parameter Expansion".
(2) Install bash_builtins.1 on a system using man-db (e.g., debian or
suse)
and try "man bash_builtins".
Fix:
For (1) and (2) apply these two patches.
-- cut here ---
diff -ur -x configure bash-3.2.orig/doc/bash.1 bash-3.2/doc/bash.1
--- bash-3.2.orig/doc/bash.12006-10-03 14:54:26.0 +0200
+++ bash-3.2/doc/bash.1 2008-01-15 19:44:43.0 +0100
@@ -2539,7 +2539,7 @@
pathname expansion.
\fIParameter\fP is expanded and the longest match of \fIpattern\fP
against its value is replaced with \fIstring\fP.
-If \Ipattern\fP begins with \fB/\fP, all matches of \fIpattern\fP are
+If \fIpattern\fP begins with \fB/\fP, all matches of \fIpattern\fP are
replaced with \fIstring\fP. Normally only the first match is replaced.
If \fIpattern\fP begins with \fB#\fP, it must match at the beginning
of the expanded value of \fIparameter\fP.
-- cut here ---
diff -ur bash-3.2.orig/doc/builtins.1 bash-3.2/doc/builtins.1
--- bash-3.2.orig/doc/builtins.12004-05-24 16:19:55.0 +0200
+++ bash-3.2/doc/builtins.1 2007-03-28 22:20:48.0 +0200
@@ -10,6 +10,6 @@
ulimit, umask, unalias, unset, wait \- bash built-in commands, see
\fBbash\fR(1)
.SH BASH BUILTIN COMMANDS
.nr zZ 1
-.so bash.1
+.so man1/bash.1
.SH SEE ALSO
bash(1), sh(1)
-- cut here ---
It would be nice if something could be done about (3).
Re: PATH value doesn't get updated
В Пнд, 12/05/2008 в 17:02 -0600, Bob Proulx пишет: > The $0 is the name used to invoke the shell. If it starts with a '-' > then this is used to instruct the shell that it is a login shell. The > second variable $- is the flags set to the shell. The 'i' for > interactive should be in there. Actually that's not exactly true. It's possible to start bash as login shell but - will be absent. Quoting relevant part of manual: "A _login_ shell is one whose first character of argument zero is `-', or one invoked with the `--login' option." Better way to check if shell is login is: $ shopt | grep login_shell login_shell on -- Peter.
$HOSTTYPE
Hello, How does bash determine $HOSTTYPE? Is it dependent on the version of bash installed - if I install i586 packages on an x86_64 platform, will $HOSTTYPE be i586? (I wouldn't've thought so, but I wanted to check.) Thanks in advance for any help; and apologies if I'm missing somewhere I could easily find this out. cheers, - Peter -- PRAGUE: Home of the world's finest beer -- http://prague.tv/toys/beer/
Directing into a variable doesn't work
With memory being abundant and filesystem access expensive, I want to put stdout and stderr of a command into variables (without needing to write to a file): output=$($command 2>>>errors) Or: $command >>>output 2>>>errors Obviously this gives a syntax error now, as this intuitive idea isn't implemented (yet). Any chance for a fix, to introduce an operator >>> that functions as a "reverse here-document" that stores the content of a file stream into a variable? I think that would be very useful extension, easy to comprehend in the light of current syntax, and not clashing with anything existing as far as I can see. Peter
Re: Directing into a variable doesn't work
Thank you for the feedback, very insightful. Yes, scratch that first 'example'. Yay for the here-variable redirection! I am surprised by the general internal usage of temporary files for here-documents & here-strings, because (generally speaking) memory is quite abundant, and here-strings and even here-documents are usually not huge. I can see for memory-depleted systems this might be an issue, and there are no definite guarantees about the eventual size that is required, but (again, generally) this could all be done in memory. (And how about storage-depleted systems??) Peter On 06/24/2018 05:38 PM, Martijn Dekker wrote: > Op 24-06-18 om 05:08 schreef Peter Passchier: >> With memory being abundant and filesystem access expensive, I want to >> put stdout and stderr of a command into variables (without needing to >> write to a file): >> >> output=$($command 2>>>errors) > > This would not work even if the feature is implemented. The $(command > substitution) forks a subshell process to execute the command in, > because the main shell process needs a process it can set up a pipe > with. So the 'errors' variable would only exist in that subshell process > and would be lost as soon as the command substitution completes. > >> Or: >> >> $command >>>output 2>>>errors > > This form seems conceivable to me. > > However, note that here-documents and here-strings internally use > temporary files, so they do involve file system access. I'm not Chet, > but I don't think that would be different for your proposed feature. So > while this might be some nice syntactic sugar, I'm afraid you would be > disappointed about the performance. > > I still kind of like the idea, though. As far as I know, there's > currently no way to capture more than one output stream into separate > variables without involving rather laborious handling of temporary > files. Your proposal would probably still involve that, but the shell > would do the hard work for you which seems like an improvement to me. > > BTW, 'reverse here-document' doesn't sound quite right. You're not > specifying any document or string containing input, you're specifying a > variable in which to store output. So, here-variable? > > - M. >
Re: Directing into a variable doesn't work
On 06/25/2018 12:27 AM, Robert Elz wrote: > That's not the real issue - rather it is that a here doc is presented to the > command beng run as a file descrptior OK, thanks, that makes sense. In the case of a here-variable, that would definitely be the case then. Peter
Re: Directing into a variable doesn't work
On 06/25/2018 08:11 PM, Chet Ramey wrote: > The answer is ultimately the same as it was last month: > > http://lists.gnu.org/archive/html/bug-bash/2018-05/msg00056.html Oh wow, you replied..! I never got this in my inbox somehow... I guess it is syntactic sugar (although Greg's post shows it isn't entirely straightforward to implement in bash). But it's a useful addition and making sense given existing syntax. So now just hoping for someone to do a sample implementation!! Thanks, Peter
man bash does not list 'in' as a builtin command
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='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib - Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash- N2nMjo/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format- security -Wall -Wno-parentheses -Wno-format-security uname output: Linux Precision 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 20 Release Status: release Description: 'in' is a builtin command and is not listed in the man page as such. Repeat-By: type at the bash command line: $ in bash: syntax error near unexpected token `in' $ which in $ Or how I found out about this issue (I did not test the below): $ cd $ mkdir bin $ PATH=$HOME/bin:$PATH $ echo 'echo test in script' | tee -a ~/bin/in $ chmod 755 ~/bin/in $ which in /home/user/bin/in $ in bash: syntax error near unexpected token `in' $ Then, test the script does work just fine $ ./in test in script $ Why is this bug report important? Why change the man page? I wasted 20 minutes of my time, to prove to my satisfaction that 'in' was not invoking my script at all. Search engines did not find a match to the error message. I can not imagine this report is the first time this bug was found.
Re: man bash does not list 'in' as a builtin command
ency would be a focus of those forum threads.
Given, "in" is a unique case, there likely will never be a "consistent
policy" for it, until there is an addition to bash, of a second such
RESERVED WORD, that can never be used as the first word. Only then,
will any progress be made in determining, in discussing, in setting a
consistent policy.
So, I forgo thinking that 'now' is good time to discuss policy. It
would waste everyone's time, as compared to making this a single
management decision, to make a one time edit to the man page.
I see the issue as one of: Is there a volunteer who can step up to make
code changes and man page edits, for this issue, that the other
involved configuration control staff can 'quickly' agree to, so as to
not waste the volunteer's time and effort?
That said, any improvement in the man page, would be faster than coding
and testing. Managing this issue as solely a documentation change is
easy at this time. Very easy, compared to doing a change to the syntax
parsing error processing algorithm, for this one "unique" RESERVED
WORD. A man page edit is my recommendation. No code changes.
And when a second such RESERVED WORD is invented, only then would code
changes be justified, the volunteer time be worth it, in addition to
the man page edit to support the behavior coded into bash for this
second word. And even then, perhaps the third reserved word is the
decision point, not the second, as again, for the second word, easy,
lowest cost, by far, is to the edit the man page to cover the
condition.
Only the expert coder of the 2nd word would truly know the cost benefit
of changing the syntax error message, to reflect the true condition.
I have not looked at the code, so ... I defer to the experts, and the
druthers of the coder of the 2nd reserved word syntax parsing. And to
those who talk to him, and ask him, what is the effort level, to
support a truly useful error message, for the 2nd word, and if they
would code the same for the word "in".
That's one man's opinion. He is not changing it.
Peter
P.S. Volunteer time is the most precious commodity on this planet. It
created "Ecology." Which then cleaned up the air, water and food, and
greatly increases the quality of living for every individual on this
planet. Volunteer time generates over 100 trillion dollars in economic
benefit via the concept of "open source" - code that rejects the past
failures, since 1957, on how not to implement an algorithm, and used
only the best algorithm known at the time. Open source will enable us
to travel to the rest of Solar System, and see the Milky Way. That
Pale Blue Dot is the single nest of humanity. We must get off this
planet, for long term survival. Only Open Source can do this, as it's
less expensive. You heard it here first.
On Mon, 2019-11-25 at 20:15 -0500, Clint Hepner wrote:
> > On 2019 Nov 25 , at 4:43 p, Peter Benjamin
> > wrote:
> >
> >
> > Description:
> > 'in' is a builtin command and is not listed in the man page as
> > such.
> >
> > Repeat-By:
> >
> > type at the bash command line:
> >
> > $ in
> > bash: syntax error near unexpected token `in'
>
> This should be a big hint that it is *not* a built-in command. If it
> were, you would have run the command, not gotten a syntax error.
>
> >
> > Why is this bug report important? Why change the man page? I
> > wasted
> > 20 minutes of my time, to prove to my satisfaction that 'in' was
> > not
> > invoking my script at all. Search engines did not find a match to
> > the
> > error message. I can not imagine this report is the first time
> > this
> > bug was found.
>
> Given that ``in'' *is* documented as a reserved word
>
> RESERVED WORDS
>Reserved words are words that have a special meaning to
> the shell. The
>following words are recognized as reserved when unquoted
> and either the
>first word of a simple command (see SHELL GRAMMAR below)
> or the third
>word of a case or for command:
>
>! case coproc do done elif else esac fi for function
> if in select
>then until while { } time [[ ]]
>
> the question becomes, what change to the man page do you think would
> have helped you
> find this more quickly?
>
> One thing that comes to mind would be a short (though off-topic)
> entry in
> the SHELL BUILTIN COMMANDS section, like
>
> in
> See the Compound Commands section under SHELL GRAMMMAR. Used
> to form the ``case'', ``select'', and ``for'' commands.
>
> I don't really li
Re: man bash does not list 'in' as a builtin command
On Tue, 2019-11-26 at 18:26 +0700, Robert Elz wrote: > With that in mind the message in question isn't really confusing at all. I agree. With one little exception. Bash has two levels of error checking, that can generate the message. 1) Command line parsing and interpreting. 2) Bash script parsing and interpreting. I looked first into the latter, my new code is always thought to have the error, before I suspect open source software quality. Then, I started suspecting the former, the CLI, then confirmed it. And it could only happen for the one word, 'in', and no other. A very special case indeed. No worthy of time to edit and debug and QA software. @Robert: Down Under is a very fine place to live, indeed. @Chris: I like the 'type' command. Thanks. BTW, I have named thousands of custom scripts, one letter, 2, 3, or 2 to 8 words, etc. Never had a problem with figuring out an error message, until this one. 'in' was the initials of the longer two words I wished to name it, but for keystroke counting purposes I wanted just two letters. I was going to use the command frequently for some days, 20-50 times a day. A testing script. I settled on 'inn' being next fastest to type. Peter
I am not even remotely sure whether this is a bug: redefining getenv/setenv/et al.
So, for context, I'm aware that this is by no means a normal or reasonable use
case. I'm the maintainer of pseudo, a program used by build systems to allow
developers to create filesystems with permissions, modes, and device nodes,
without actually requiring root privileges. (Similar to fakeroot.)
Pseudo works by preloading itself as a shared library, using LD_PRELOAD (on
Linux), and replacing large hunks of the C library. The client code can
spawn a server, which of course doesn't want LD_PRELOAD set.
And I have for some time had a very strange problem, which is that
"sometimes" unsetting LD_PRELOAD doesn't work. Well, it turns out that the
issue is that bash provides its own definitions of getenv/setenv/unsetenv,
and they don't automatically modify environ.
It seems pretty obvious to me that there are Sound Technical Reasons for the
shell to wish to maintain an "environment" which is not actually stored in
environ, so that part makes sense.
What surprised me is the use of the same names as the C library functions
which manipulate environ. I had a bit of test code to the effect of:
char *u = getenv("LD_PRELOAD");
pseudo_diag("LD_PRELOAD: %s\n", u ? u : "");
for (int i = 0; environ[i]; ++i) {
if (!strncmp(environ[i], "LD_PRELOAD=", 11)) {
pseudo_diag("environ[%d]: %s\n", i, environ[i]);
}
}
and this would emit things like:
LD_PRELOAD:
environ[75]: LD_PRELOAD='libpseudo.so
which was very, very, surprising. I showed this behavior to a fair number of
people, and none of them thought of "is it possible that the process your
library is attached to has redefined getenv and setenv?".
So what I'm wondering is, why were these functions given the same names as
the library functions, rather than having names like bash_setenv, etc? It
seems risky. (I think it's technically undefined behavior, but as the person
whose library replaces most file-related calls with custom versions that talk
to a database server to fake results, I think I'll refrain from throwing
stones on that topic.)
-s
--
Listen, get this. Nobody with a good compiler needs to be justified.
No such file..?
I downloaded a Solaris binary and I was wondering whether I could get it to execute with the --version commandline argument (it worked for an arm7 binary before). But that's not what concerns me. $ /home/pp/bin/caddy --version -bash: /home/pp/bin/caddy: No such file or directory $ file /home/pp/bin/caddy /home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/amd64/ld.so.1, not stripped $ ls -AFl /home/pp/bin/caddy -rwxr-xr-x 1 pp pp 16229894 2017-05-05 10:30 /home/pp/bin/caddy* I would think that is a strange response... Peter
Re: No such file..?
What I should have clarified:
- This is on Linux
- I am not concerned with the binary not working, but I think the error
message is unclear and misleading.
$ ldd /home/pp/bin/caddy
/home/pp/bin/caddy: error while loading shared libraries:
/usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
$ strace -e open,stat,execve -f /home/pp/bin/caddy
strace -e open,stat,execve -f /home/pp/bin/caddy
execve("/home/pp/bin/caddy", ["/home/pp/bin/caddy"], [/* 74 vars */]) =
-1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
$ file /home/pp/bin/caddy
/home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib/amd64/ld.so.1, not stripped
$ /home/pp/bin/caddy
-bash: /home/pp/bin/caddy: No such file or directory
The output from bash is misleading. The file is there. Couldn't the
error message be more descriptive of what's the actual problem?
Peter
On 05/05/2560 20:01, Eduardo Bustamante wrote:
> On Thu, May 4, 2017 at 10:57 PM, Peter Passchier wrote:
> [...]
>> $ file /home/pp/bin/caddy
>> /home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>> dynamically linked, interpreter /lib/amd64/ld.so.1, not stripped
>
> (I'm assuming you're trying to run this in a Linux system)
>
> Can you show:
>
> - The output from: ldd /home/pp/bin/caddy
> - The output from: strace e open,stat,execve -f /home/pp/bin/caddy
>
Re: No such file..?
Thanks for looking into this.
I guess this shows it isn't always helpful to just pass down error
messages. Bash knows it's trying to execute something. It doesn't work
out. For the naive user of a shell, it would be more helpful to have it
come back with:
Couldn't execute ...
Because the problem is, it can't execute the requested file. A more
descriptive error from the kernel would be great, but if that's not
available, bash should be aware of what it's trying to do, and give back
an appropriate error. This is just wrong. If I do /ewdedwededqwd bash
comes back with the same message. Strace in this case will say "Can't
stat", not "exec: No such file or directory"
Peter
On 06/05/2560 07:59, Eduardo Bustamante wrote:
> On Fri, May 5, 2017 at 7:44 PM, Peter Passchier wrote:
> [...]
>> The output from bash is misleading. The file is there. Couldn't the
>> error message be more descriptive of what's the actual problem?
>
> Bash has no way of knowing what the problem is. Bash will do:
>
> execve("...")
>
> to the binary you provided. The kernel will then return "ENOENT" (from
> https://linux.die.net/man/2/execve, "ENOENT - The file filename or a
> script or ELF interpreter does not exist, or a shared library needed
> for file or interpreter cannot be found."). Bash sees the ENOENT
> error, and prints the strerror() corresponding to that error, which is
> "No such file or directory".
>
> Bash would need an error code more specific than ENOENT from the
> kernel to be able to distinguish between. ENOLIB or something.
>
> Most likely no other shell or tool does this anyways. You can see that
> strace tries to execve the tool, and it prints the same error as bash.
>
Why bash stops process in background?
Hello. I need to run ssh in background just to forward ports. But anytime I put it into background process state became stoped and this does not allow me to send packets through forwarded ports. 'bg' command does not help. How can I tell bash not to stop process? I've tried to trap signals, but I can not trap STOP signal. What else can I do? I'm using: [EMAIL PROTECTED] ~ $ bash --version GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. Thank you for your time, Peter. P.S. I'm not subscribed to the list, so please CC me. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Spam] Re: Why bash stops process in background?
On Чтв, 2005-08-25 at 08:46 -0600, Bob Proulx wrote: > Peter Volkov Alexandrovich wrote: > > P.S. I'm not subscribed to the list, so please CC me. > > > I need to run ssh in background just to forward ports. But anytime I put > > it into background process state became stoped and this does not allow > > me to send packets through forwarded ports. 'bg' command does not help. > > Very likely the ssh program is trying to do I/O. The kernel will > notice this and stop the process so that you can bring it into the > foreground and interact with it. > > This really has nothing to do with bash and is simply the behavior of > BSD style job control as implemented by the kernel. Very interesting. I did not know that. Thank you for explanation. > Try giving ssh the -n option. Also, you may want to use -N too. Here > is the ssh man page snippets. [snip info from man page.] Yes. -nN options help me. Thank you, Bob, again, Peter. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: have the same column L
Assuming the input is hexadecimal, a function like this would format
each line as intended:
formatline() { printf "%010X \n";}
Then a line like this would give the intended result:
while read -r; do fl $REPLY; done
Hi all,
How can I starndarzied string column to have the same column length for each
row.
Example
filename
A135953
D10036050
C135858000
I want add leading zeros and the column length should be 10
I tried
awk '{ printf "%010s \n", $1}' filename
Got all zeros
00
00
00
00
But I want
000A135953
0D10036050
C135858000
I would appreciate if you help me out.
thank you in advance
--
View this message in context:
http://gnu-bash.2382.n7.nabble.com/have-the-same-column-L-tp19574.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: extension of file-test primitives?
Sorry, indeed I meant: [[ -fx $file ]]
All -ge -ne -eq etc. options are binary operators, while these new ones
wpuld be unary, so I think the parsing would be unequivocal.
Peter
On 08/21/2017 04:20 AM, L A Walsh wrote:
PePa wrote:
In that case, would not [[ =fx $file ]] be more workable and in line
with common GNU short commandline option practice??
Do you mean '-fx' ? I assume you are meaning as an alternate?
It would be fine with me, even better on an aesthetic sense, however,
Bash already has multi-character ops starting with a dash.
While "-ge $file" could probably be parsed reliably apart from
"$file2 -ge $file", they look similar to a human and might create
more confusion than help. (-ge $file == exists & groupid set), vs
testing contents of integer vars $file2 and $file for integer-var $file2
being greater-than-or-equal to integer-var $file.
Leveraging the curly brace format, implying [[ -{g,e} $file ]] would be
similar to the quoted example I mentioned. I.e. -- it would be
a matter of applying brace expansion even though quotes didn't exist.
I.e. instead of:
eval 'test -'{g,e}' /bin/ls && :' && echo executable file
one could remove the eval, quotes and extra '&& :' at the end and
use:
test -{g,e} /bin/ls && echo executable file
I _think_ people who are familiar w/brace expansion would
easily understand this new form and not confuse it with
existing features.
Does that make sense?
-l
Re: extension of file-test primitives?
On 08/23/2017 07:36 PM, Greg Wooledge wrote: Second, you proposed test -fx. But this collides with existing multi-character test options. Specifically, test has the options -e, -f, and -ef. So your proposal of letter-concatenation would take the -e and -f options and squash them together into -ef, which would collide with the "two files are hard links to the same inode" option. Likewise, the unary options -n and -t would combine into -nt which collides with the binary "mtime is newer than" option. Sure, you might argue that there is no reason to combine -e and -f together, since one implies the other; or that no sane person would ever combine -n and -t together; but that's not the point. The point is to avoid reader confusion. It's already bad enough that the -a option is overloaded and has two completely different meanings. Let's not compound that mistake. I was the one proposing combining the UNARY operators in a way like -fx, and your -a example shows that there is a precedent. Unary and binary operators are different, so there is no confusion for the parser or for the user. It would just work for the person who would like to use it. The combining would only be allowed (and only make sense) for the unary operators, and it would lead to a much cleaner and more readable source. It is also in line with common GNU combining-short-options syntax. Users might even expect this to work already. This change would not hurt backwards compatibility and enhance bash in a clean way, making things more readable where they would/could be used. Peter
Re: [here string] uncompatible change on here string function
On 11/22/2017 08:04 PM, Greg Wooledge wrote: wooledg:~$ bash-4.2 wooledg:~$ var=$'foo\t\tbar' wooledg:~$ cat <<< "$var" foo bar I think you are missing the point. He is claiming/reporting: $ bash-4.4-12 $ var=$'foo\t\tbar' $ cat <<<$var foo bar # Without the quotes, the tabs still get expanded, that should not # happen, they should collapse into 1 space, this is a bug if true. Peter
Re: Issue – Invalid command documented – BASH_BUILTINS(1) –
On 07/14/2018 09:38 PM, Ricky Tigg wrote: > $ man 1 bash_builtins The variable is BASH_BUILTINS but the man page is bash-builtins (underscore vs. dash). Peter
Re: "here strings" and tmpfiles
On 10/4/2019 09:04, Greg Wooledge wrote: > On Wed, Apr 10, 2019 at 11:59:19AM -0400, Daniel Kahn Gillmor wrote: >> If we look at the problem from the perspective of the risk of >> herestring/heredoc content leaking to non-ephemeral storage, > > The content is already in the damned SHELL SCRIPT. > > How much more "non-ephemeral" can it get? Both herestring and heredoc often contain variables, or some other process substitution, for them to be completely literal is a less interesting case for this issue. Peter
Re: The "-e" test ingores broken links
WHich docs? If I do "help test" it states: "All file operators except -h and -L are acting on the target of a symbolic link, not on the symlink itself, if FILE is a symbolic link." Peter On 14/10/2559 02:00, Łukasz Grabowski wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i586 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CON > FIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g > -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall > uname output: Linux brutus 3.16.0-4-686-pae #1 SMP Debian > 3.16.36-1+deb8u1 (2016-09-03) i686 GNU/Linux > Machine Type: i586-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > according to docs -e test should return true when tested on files, > including broken links, but it doesn't > > Repeat-By: > the two commands > ln -s xxx a > if [ -e a ]; then echo "exists!"; fi > don't produce any output on my system > > > Best, > Łukasz Grabowski >
BUG??
Is this a bug? These both output "q=1" q=1 [[ ((q==1)) ]] && echo q=1 q=0 [[ ((q==1)) ]] && echo q=1
Re: Bug? Explanation??
Thanks Dennis and Grisha! I understand. I had thought that every line that is piped into bash is it's own shell alignment, but I understand it's more like sourcing, so these would be more or less equivalent, right? r=23; echo $r; echo -e 'r=bc\necho $r' >r; source r r=23; echo $r; echo -e 'r=bc\necho $r' |bash Thanks again, Peter On 31/12/2559 11:07, Grisha Levit wrote: > On Fri, Dec 30, 2016 at 11:03 PM, PePa <mailto:peterke...@passchier.net>> wrote: > > r=23; echo $r; echo -e "r=bc\necho $r" |bash > > You need to escape the |$| in the second echo statement so that |$r| is > not evaluated to |23| before being echoed. > >
Re: Bug? Explanation??
I guess they are not equivalent, piping into bash opens a subshell, and sourcing doesn't; these act differently: echo exit |bash echo exit >r; source r Hope I've gotten it right now. Thanks, Peter On 31/12/2559 11:20, Peter & Kelly Passchier wrote: > Thanks Dennis and Grisha! I understand. > > I had thought that every line that is piped into bash is it's own shell > alignment, but I understand it's more like sourcing, so these would be > more or less equivalent, right? > > r=23; echo $r; echo -e 'r=bc\necho $r' >r; source r > > r=23; echo $r; echo -e 'r=bc\necho $r' |bash > > Thanks again, > Peter > > > On 31/12/2559 11:07, Grisha Levit wrote: >> On Fri, Dec 30, 2016 at 11:03 PM, PePa > <mailto:peterke...@passchier.net>> wrote: >> >> r=23; echo $r; echo -e "r=bc\necho $r" |bash >> >> You need to escape the |$| in the second echo statement so that |$r| is >> not evaluated to |23| before being echoed. >> >> >
Re: echo -n
Depending on your use case, you could do something like: $ echo $'\u2010'n -n On 06/02/2560 13:37, Clark Wang wrote: > On Mon, Feb 6, 2017 at 12:15 PM, Jyoti B Tenginakai > mailto:jyoti@in.ibm.com>> wrote: > > Thanks you all, > > Again I see that this printf we can use. But there are some > scenarios where the o/p does not exactly match with echo. So still > its good to have a way to pirnt -n /-e/-E with echo. Can this be > considered as bug and can this be fixed? > > It’s not a bug. According to POSIX.1-2008: > > The |echo| utility shall not recognize the |"--"| argument in the > manner specified by Guideline 10 of XBD Section 12.2; |"− −"| shall > be recognized as a string operand. > > It is not possible to use |echo| portably across all POSIX systems > unless both |−n| (as the first argument) and escape sequences are > omitted. > > The |echo| utility has not been made obsolescent because of its > extremely widespread use in historical applications. > >
Re: "unset var" pops var off variable stack instead of unsetting it
On 20/03/2560 04:51, Stephane Chazelas wrote: > On comp.unix.shell ot http://unix.stackexchange.com, I've posted > many articles describing how to do splitting in POSIX-like > shells: > > ( # subshell for local scope > unset -v IFS # restore default splitting behaviour > set -o noglob # disable globbing > cmd -- $var # split+glob with default IFS and glob disabled > ) > > I'm now considering adding a note along the lines of: > > "Beware that with current versions of bash, pdksh and yash, > the above may not work if used in scripts that otherwise use > typeset/declare/local on $IFS or call a function with > `IFS=... my-function' (or IFS=... eval... or IFS=... > source...)" > Wouldn't it be better to avoid using a function like 'unset' (that works in the way you purport to expect) in a dynamically scoped language as a matter of principle?? If unset works like you would want/expect it, it would also discard all values of all higher scopes. Would it not be better to set IFS to the value desired (whatever default splitting behaviour you need)?? -- Peter
Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"
On 22/03/2560 01:32, Martijn Dekker wrote: > A workaround for the original poster's problem could be: > > (unset -f jobs; unalias jobs; eval 'jobs -l') | wc 'unset -f jobs' is not guaranteed to unset jobs, it might set jobs to a function definition in an earlier scope..!
Re: RFE: Please allow unicode ID chars in identifiers
On 04/06/2560 04:48, L A Walsh wrote: >> Greg Wooledge wrote: >>> Here is a demonstration of the cost of what you are proposing. In my >>> mail user agent, your variable shows up as L??v. >>> >>> Source code with your UTF-8 identifiers would no longer even be >>> READABLE >> >> What display/OS do you have that you can't run UTF-8 on? So it's his mail client: reading unicode source in their old mail client is going to be problematic for some people... Peter
Re: Patch for unicode in varnames...
On 05/06/2560 15:52, George wrote: > there's not a reliable mechanism in place to run a script in a locale > whose character encoding doesn't match that of the script >From my experience running such scripts is no problem, but correct rendering it might depend on the client/editor.
Re: Patch for unicode in varnames...
On 06/06/2560 05:39, George wrote: > So if you had "Pokémon" as an identifier in a Latin-1-encoded script (byte > value 0xE9 between the "k" and "m") and then tried running that script in a > UTF-8 locale, that byte sequence (0xE9 0x6D) would actually be invalid in > UTF-8, so Eduardo's patch would indicate that the identifier is invalid and > fail to run the script. I often work with a locale that has a UTF-8 encoding and an different/older encoding that are incompatible. I haven't tried the patch, but if I use unicode characters in function names, if I write a script in one encoding, and run it in an environment in the other encoding, it still runs correctly, but it won't render correctly. (I guess this depends whether the editor recognizes different encodings, like Geany does render it correctly, but I don't know of a console editor that does that.) Peter
Re: Patch for unicode in varnames...
On 06/06/2560 14:37, George wrote: > As it stands, it's possible in Bash to use bytes in the 0x80-0xFF range as > part of function names, for instance, because the Bash parser treats all of > these byte values as valid "word" characters. This makes the Bash parser > fairly "encoding neutral", which is why scripts using non-ASCII characters in > command names or function names work even if the script is run on a different > locale in current versions of Bash. Bash just ignores the issue, and > that works for a fair number of encodings. Thanks for the elucidation. Sorry, my terminology was off. I meant to say, same glyphs, different encodings/locale. A TIS-620 encoded script works in UTF-8, like you said above. Peter
Re: Patch for unicode in varnames...
On 06/06/2560 14:37, George wrote: > Broadly speaking I think the approach taken in Eduardo's patch > (interpreting the byte sequence according to the rules of its character > encoding) is better than the approach taken in current versions of Bash > (letting 0x80-0xFF slide through the parser) - but that approach only > works if you know the correct character encoding to use when processing > the script. The information has to be provided in the script somehow. I think only supporting UTF-8 would be the easiest, it allows all glyphs to be used. And no extra declaration needs to be added to bash. Peter
Re: Patch for unicode in varnames...
On 08/06/2560 04:33, Dethrophes wrote: > This would be a bad idea in the same way that having control characters in > filenames is a bad idea, just because you can do something doesn't mean you > should. I would personally advocate NOT to use it in code. But then, I am biassed by upbringing towards ASCII... But, I wouldn't want others to be deprived of the option. Remember, function names, and aliases already can be in unicode encodings! Which probably already helps shell endusers the most. But allowing variable names in unicode is a logical progression, and as we can see from Eduardo's quick patch, doesn't involve a big overhead in added complexity. (Advocating because of living now in a country with a different script.) Peter
Re: Trailing newlines disappear
On 09/06/2560 00:42, Greg Wooledge wrote:
> It's not a bug. This is how command substitution has worked since
> the original Bourne shell.
>
> The workaround is to put something inside the command substitution,
> so that the newlines aren't trailing any more, and then strip it away
> afterward:
>
> foo=$(cat "$file"; printf x) foo=${foo%x}
Thanks for the reply.
Seeing the hackish workaround, I would call it an ossified (or codified)
flaw...
The workaround I came up with is:
mapfile <"$file"; IFS= foo=${MAPFILE[@]}
This seems to be faster, but it probably has other disadvantages...
Peter
Re: Trailing newlines disappear
On 09/06/2560 03:44, Geir Hauge wrote:
> Greg already pointed out that this doesn't work.
>
> You can pick one of these instead:
>
> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>
> or
>
> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
>
Yes, thanks.
The second one looked interesting, but didn't work. I now have:
mapfile <"$file"; IFS= foo="${MAPFILE[*]}"
(without the unset, as it's in a function where it's harmless)
Re: Trailing newlines disappear
On 09/06/2560 05:26, Eduardo Bustamante wrote: > What's wrong with: > > IFS= read -rd '' foo < "$file" I think that's the winner!
Re: Trailing newlines disappear
On 09/06/2560 23:38, L A Walsh wrote: > Chet Ramey wrote: >> >> Should mapfile silently drop the NULs? > > Maybe add a flag to ignore NUL bytes that could be used in the 'read' > statement as well? If not specified, keep same behavior? That sounds like it might be useful. It might be more desirable to change it to a newline instead of dropping it? (Or both, with different flags??) And how about a shell option to not omit trailing newlines in command substitutions?? I find that very undesirable and unnecessary behaviour. Peter
Re: Trailing newlines disappear
On 13/06/2560 02:54, Chet Ramey wrote: > If you want to effectively change it to a newline, specify NUL as the > line delimiter using the -d option (new in bash-4.4). Thanks, that sounds like a clean solution! I only reverted to mapfile because $(...) command substitution could not be made to work. (I still have to 'convert' the array to a normal variable in the next step...). Would a shell option for command substitution using NUL be a desirable feature to bash users?? Peter
Re: Trailing newlines disappear
On 14/06/2560 03:52, Chet Ramey wrote: > You mean command substitution cutting off the input it reads at the > occurrence of a NUL? What I am really after is a shell option for command substitution not discarding trailing newlines. Peter
Re: people working in Greg's locale (+euro) & display of Unicode names
On 16/06/2560 03:11, Chet Ramey wrote: > You still have to look at every character. The world isn't all UTF-8: > there are character sets where multibyte characters include characters > that are valid ascii (including, I suspect, `='). I think supporting all kinds of other encodings besides UTF-8 is absolutely nuts. You not only have to look at every character, but you first have to decide which encoding you're going to be in, and this might be ambiguous (unless an encoding declaration becomes part of bash). I think the overhead in code size and complexity will be too much. I never thought you were thinking in this direction. I hope other people will chime in about this approach. Peter
