Re: degraded error message in case of hash-bang interpreter error
On Monday, November 4, 2024, Martin D Kealey wrote: > POSIX says that the execve syscall reads the name of an interpreter (and > options) from a '#!' line, > Where? -- Oğuz
Re: recent typo in sig.c breaks Minix compilation
On Friday, October 18, 2024, Martin D Kealey
wrote:
>
> The problematic code for editors looks like this:
>
> #ifdef FOO
> if (foo && zot) {
> #else
> if (bar && zot) {
> #endif
>
> Vim certainly does not like this,
>
How about this:
#ifdef FOO
if (foo && zot)
#else
if (bar && zot)
#endif
{
--
Oğuz
Re: recent typo in sig.c breaks Minix compilation
On Friday, October 18, 2024, Martin D Kealey wrote: > > Talking of which, I note several places where there's a construct like: > > #ifdef FOO > > if (foo && zot) > > #else > > if (zot) > > #endif > > > Unfortunately this confuses both the indent program and some editors. > It looks a lot cleaner than the alternatives you provided. What are the names of these editors? -- Oğuz
Re: procsub doesn't release the terminal without reading one byte
On Sun, Oct 13, 2024 at 3:18 AM Chet Ramey wrote: > You have two processes fighting over stdin. Why though? Can't bash just close the procsub's stdin when `:' returns?
Re: waiting for process substitutions
On Saturday, October 12, 2024, Zachary Santer wrote: > > Backwards compatibility with people's expectations No one expects children of the same parent to be able to wait for eachother. It's common sense. -- Oğuz
Re: fg via keybind modifies tty settings
On Saturday, October 12, 2024, David Moberg wrote: > This link shows a big commit to bash. Is it merged to main/release? Can I > try it out? > You can clone the devel branch to try it out. The master branch is only updated for releases and important patches. -- Oğuz
procsub doesn't release the terminal without reading one byte
The first letter I type after running this command won't show up on the terminal: : < <(cat) This is reproducible on 5.3 beta too. Oğuz
Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On Saturday, September 21, 2024, Koichi Murase wrote: > > Emacs has `auto-mode-alist'. VS Code has `files.associations'. > I think he meant a command line option. Like something you can put in FCEDIT -- Oğuz
Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On Fri, Sep 20, 2024 at 12:00 PM shynur . wrote: > Editors needn't give "bash-fc.NN" special handling, IMO. A good editor would.
Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On Fri, Sep 20, 2024 at 11:20 AM shynur . wrote: > - When Emacs opens a file named "bash-fc.NN.bash", > it'll enable sh-mode automatically Vim does that without the .bash extension. What stops Emacs from doing the same?
Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On Friday, September 20, 2024, shynur . wrote: > > editors that use *suffixes* to infer what syntax > highlighting should be enabled. > For example? -- Oğuz
Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)
On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso wrote:
>
It boils down to this:
f(){ echo $#;}; set "" "" ""; IFS=x; f $*
bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh
prints 3 but mksh and oksh print 1. dash, ksh93, yash, and zsh print
0.
Re: 'wait -n' with and without id arguments
On Monday, September 9, 2024, Zachary Santer wrote: > Slightly improved wait-n-failure attached. It's >100 lines and your replies are too long. Summarize what you want so others can contribute too without having to waste time reading the whole thread. -- Oğuz
Re: please make the commit log clean
On Monday, August 19, 2024, Koichi Murase wrote: > > One can put " diff=no" in .git/info/attributes to > ignore these files in `git diff'. This is a very good idea. Marking auto-generated files as binary in /.gitattributes would address OP's concerns without changing how Bash is built. -- Oğuz
Re: Question on $@ vs $@$@
On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > However, as ksh93 makes "" from this > expansion, and so probably ksh88 might have done as well No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.
Re: Question on $@ vs $@$@
On Wednesday, August 14, 2024, Steffen Nurpmeso wrote:
>
> one() { echo "$# 1<$1>"; }
> two() { one "$@"; }
> twox() { one "$@$@"; }
> two
> two x
> twox
> twox x
> $ dash shbug.sh
> 0 1<>
> 1 1
> 1 1<>
> 1 1
> #?0|kent:tmp$ bash shbug.sh
> 0 1<>
> 1 1
> 0 1<>
> 1 1
>
FWIW, POSIX doesn't pick sides on this; XCU 2.5.2 <
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_05_02>
says:
If there are no positional parameters, the expansion of '@' shall generate
zero fields, even when '@' is within double-quotes; however, if the
expansion is embedded within a word which contains one or more other parts
that expand to a quoted null string, these null string(s) shall still
produce an empty field, except that if the other parts are all within the
same double-quotes as the '@', it is unspecified whether the result is zero
fields or one empty field.
--
Oğuz
Re: whats wrong , exit code 11 on android termux
On Saturday, August 10, 2024, Martin D Kealey wrote: > Sorry, that was supposed to be a personal reply off-list. > Do you always harass foreigners like that or was it an exception? -- Oğuz
Re: waiting for process substitutions
On Tuesday, August 6, 2024, Zachary Santer wrote: > > This I guess makes a further point about the need to anticipate what > shell programmers might want or need to be able to do. To me it just shows how lost you are, sorry. Perhaps you should consider other languages, or write a utility that makes setting up FIFOs easier, I don't know. -- Oğuz
Re: waiting for process substitutions
On Tuesday, August 6, 2024, Zachary Santer wrote: > > How bash is actually used should guide its development. Correct. No one waits for procsubs in their scripts or on the command line. In a script, a child process being a job or not makes no difference, > from the shell programmer's perspective, unless you've got job control > on for some reason. That's not true. `jobs' works even if job control is disabled. `kill' accepts jobspecs and bash expands the `\j' escape sequence in prompt strings. So it does make a difference. > Only as much noise as how many procsubs you expand on the command line. > And that's too many. Much more than async jobs. -- Oğuz
Re: waiting for process substitutions
On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer wrote: > I can not think of a time when I called 'wait' from the command line > that wasn't just for testing something. Even using process > substitutions on the command line is a relative rarity for me. If > we're balancing behavior on the command line against behavior in a > script, I think I'd give priority to scripting, at least here. This belongs on your personal blog. > Chet doesn't see much value in making process substitutions jobs, > which I guess is fine. Can we agree that if they were made jobs, > though, waiting for all of them would be acceptable? You could see > them listed and handle them however you need. Making them jobs would be a bad idea. There are two major use cases of process substitutions: 1. Piping the output of a script to a command from within the script itself. 2. Creating one-off FIFO files in scripts and on the command line. Neither use case would be improved if procsubs were made jobs. And it'd create too much noise for miniscule benefit. > Bash is evidently already tracking all the procsub pids in their own > list, which now is always cleared when you call 'wait' without > arguments. It's okay as long as the user has his CHILD_MAX remembered jobs. If too much memory is used for procsubs or if they stay in memory for too long that should be fixed.
return from trap while reading with readline breaks completion
See: $ ls foo s $ cat s trap return INT read -e $ source s I press Ctrl-C here and bash prompts me for the next command. Then I press F and Tab; instead of producing the bell sound bash completes f to foo. If I press Ctrl-C again it prints "bash: return: can only `return' from a function or sourced script" and completion returns to normal. Oğuz
Re: waiting for process substitutions
On Tuesday, August 6, 2024, Zachary Santer wrote: > I > don't see the benefit over simply waiting for all process > substitutions. > The benefit is they're separate from async jobs and don't get in your way. `wait' waiting for the last procsub is acceptable, `wait' waiting for a procsub that I forgot about and that won't be listed by `jobs' is not. Procsubs occupying one slot in the shell's internal list of job statuses is acceptable, them filling up that list and causing data loss/oom errors is not. -- Oğuz
Re: waiting for process substitutions
On Saturday, July 13, 2024, Greg Wooledge wrote: > > If two jobs happen to finish simultaneously, the next call to wait -n > should reap one of them, and then the call after that should reap > the other. That's how everyone wants it to work, as far as I've seen. > > *Nobody* wants it to skip the job that happened to finish at the exact > same time as the first one, and then wait for a third job. If that > happens in the loop above, you'll have only 4 jobs running instead of 5 > from that point onward. > > It feels like deja vu all over again. Didn't we already discuss this and agree that `wait -n' should wait jobs one by one without skipping any? Did it not make it to 5.3? -- Oğuz
Re: proposed BASH_SOURCE_PATH
On Mon, Jul 8, 2024 at 11:16 AM Martin D Kealey wrote: > The only things that the shell has going for it is that it's widely deployed > and stable over the long term. > Otherwise it's a terrible language, and any sane programmer should avoid it > entirely: > This has already been happening, and Bash is >this< close to become an > irrelevant historical footnote. > If you modify Bash in ways that are not backwards compatible, you're then > writing in a new language that no new project is likely to adopt. These are just your opinions. > That's what "worth breaking existing code" costs in reality: other people's > stuff breaks when they've had zero advance notice, because they aren't the > people deciding to upgrade Bash. This I agree with, but personally I don't think the change we discuss here is that big. > PPS: In my opinion, the only hope for Bash to continue to exist in the long > term is for it to either: > (a) absolutely guarantee stability, forsaking all new features; or > (b) adopt a full suite of features that make it into a "normal" programming > language, including: support for modules written for different versions of > Bash to safely cohabitate in a single script; lexical scoping with > namespaces; being able to store references in variables, including some kinds > of handles for filedescriptors, functions, processes, and process groups; > some mechanism to perform rewriting during parsing (going well beyond what > aliases can do) so that new features can be proposed and implemented in shell > before being implemented in the C core. And all of that while not breaking > code that doesn't ask for these new features. You're wasting your breath.
Re: proposed BASH_SOURCE_PATH
On Monday, July 8, 2024, Martin D Kealey wrote:
>
> It's not possible to change "${BASH_SOURCE[@]}" without breaking some
> existing code,
>
It's worth breaking existing code in this case.
which leaves us with some kind of explicit opt-in such as:
>
`shopt -s compat52' should suffice to opt out of the new default. No point
in making it more complicated than that.
--
Oğuz
waiting for process substitutions
On Sat, Jun 29, 2024 at 8:08 PM Zachary Santer wrote: > Is that relevant? I think so. There is a limit to the number of jobs Bash can remember, once it's exceeded the oldest job is overwritten. Do we really want process substitutions to count against that limit? Or did you mean something else? -- Oğuz
Re: waiting for process substitutions
On Saturday, June 29, 2024, Zachary Santer wrote: > > Couldn't you do the exact same thing with regular background processes > forked with &? > But the shell notifies me when they terminate and reap them. -- Oğuz
Re: waiting for process substitutions
On Sat, Jun 29, 2024 at 3:47 PM Zachary Santer wrote: > Why not just wait for all process substitutions? What if I substitute thousands of processes and never call wait?
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Friday, June 28, 2024, Martin D Kealey wrote: > modern Perl scripts > No such thing. Perl is a dead language, and for good reason. Why limit this to subscripts? > Where else do you need it? > Why not use that for generating lists directly? > Doesn't brace expansion already do that? Why limit this to numeric indexing? > Because you can implement it without breaking old scripts, `a; b' is a valid associative array key. > Why not support associative arrays? > No way to do that without making array expansion syntax ten times uglier or completely changing it. Bash is too good to ruin like that. -- Oğuz
Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
On Thursday, June 27, 2024, Martin D Kealey wrote:
> [...]
That's too much to read and Perl is not a good example to follow. Why not
extend the arithmetic expansion syntax to allow generating multiple results
when subscripting indexed arrays? Like `${a[1; 2; 4]}', `${a[3..5; 7]}',
`${a[1..10..3]}', etc. These would expand like `$@' when in double quotes
and like `$*' when being assigned to a variable.
--
Oğuz
Re: function names starting with %
On Tue, Jun 25, 2024 at 3:32 PM Emanuele Torre wrote:
> There are actually ways to call them:
>
> $ %f(){ echo hi;}
> $ compgen -F %f
> bash: compgen: warning: -F option may not work as you expect
> hi
Neat
function names starting with %
You can do these
$ %f(){ :;}
$ declare -f %f
%f ()
{
:
}
$ unset -f %f
$ declare -f %f
$ echo $?
1
but not call them
$ %f
bash: fg: %f: no such job
$ '%f'
bash: fg: %f: no such job
$ \%f
bash: fg: %f: no such job
Why is that? Would it be a bad idea to let such functions take
precedence over jobspecs?
Oğuz
Re: printf, binary data, leading single quote and non ASCII codesets
On Mon, Jun 24, 2024 at 2:37 PM Gioele Barabucci wrote:
> $ printf -v b "\xc3\xbf\xbe"
>
> $ printf "$b" | { while LC_ALL=C read -N1 c; do \
> LC_ALL=C.UTF-8 printf "%d %q\n" "'$c" "$c"; done; }
> 195 $'\303'
> 255 $'\277'
> 190 $'\276'
Can't reproduce this on Ubuntu 22.04 with Bash 5.3-alpha. It says 191
here, not 255.
Re: proposed BASH_SOURCE_PATH
On Thursday, June 20, 2024, Léa Gris wrote: > > Would it be a valid option, then to make BASH_SOURCE contain the real path > in all circumstances? > Sounds good to me. -- Oğuz
Re: proposed BASH_SOURCE_PATH
On Wednesday, June 19, 2024, Will Allan wrote:
> I think this is exactly why this feature is necessary. Unless I am
> misunderstanding, simply prepending `${BASH_SOURCE%/*}' to a sourced path
> will not work in all cases. For example, when executing the main script
> directly inside the script directory (e.g. `bash main.sh`) you would end up
> with an invalid path (e.g. main.sh/../lib/foo.sh).
>
What I'm saying there is name it main and execute like `./main'. I'm not
against having a variable that's automatically populated with the parent
directory of the source script, I just don't need it and it wasn't what we
were discussing.
--
Oğuz
Re: set -a leads to truncated output from ps
On Sat, Jun 15, 2024 at 4:59 PM Koichi Murase wrote: > Sorry, I think I misunderstood the part "behind the user's back". Now I > guess you were talking about the behavior of `checkwinsize' when `set > -a' is enabled? Yes. All I'm saying is, a variable that affects how certain programs behave when exported should not be implicitly exported by the shell, the user should do it manually if he wants.
Re: set -a leads to truncated output from ps
On Saturday, June 15, 2024, Koichi Murase wrote: > > Also, the behavior of the `ps' command honoring COLUMNS to format its > output is also an expected one. > The fact that programs giving precedence to COLUMNS over the terminal API are so common is an argument against exporting COLUMNS behind the user's back though. Right now, if you're dealing with such a program while `set -a' is in effect, in order to suppress COLUMNS you need to unexport it before every command: $ set -a $ env | grep COLUMNS $ env | grep COLUMNS COLUMNS=64 $ $ declare +x COLUMNS $ env | grep COLUMNS $ env | grep COLUMNS COLUMNS=64 This is true for non-interactive shells where job control is enabled as well. If Bash didn't export COLUMNS implicitly but you wanted it to take effect, you'd export it yourself once and it'd work fine. Clean and straightforward. -- Oğuz
Re: set -a leads to truncated output from ps
On Thursday, June 13, 2024, Chet Ramey wrote: > > The value of COLUMNS gets modified, and auto-exported since you have > `set -a' enabled. > Okay, so the documentation adds up. Doesn't mean it's not a bug. If you were a normal user and were faced with the behavior presented in OP, wouldn't you think something was broken? What keeps Bash from exempting LINES and COLUMNS from `set -a' other than "it's been like this forever"? -- Oğuz
Re: it, soRE: set -a leads to truncated output from ps
On Thursday, June 13, 2024, Alain BROSSARD wrote: > > export COLUMNS=60 > > ps ax | grep java > > > > The output isn’t truncated. > > It is on my machine. You must have something in your PS1/PROMPT_COMMAND interfering. > It is critical that application’s behaviour do not get impacted by the > shell used to call them. > > Even more reason to use `ps axww' instead of `ps ax'. > What do you think ? > > I think there's at least one Bash bug involved here. -- Oğuz
Re: set -a leads to truncated output from ps
On Thursday, June 13, 2024, Alain BROSSARD via Bug reports for the GNU Bourne Again SHell wrote: > ># however, the second one has truncated output to the terminal width > Looks like `set -a' exports COLUMNS for some reason, this must be a bug $ set -a $ env | grep COLUMNS $ env | grep COLUMNS COLUMNS=64 You should call ps with the option -w if you want wide output though. On some implementations you can disable truncation completely by specifying it twice like `ps axww'. -- Oğuz
Re: read reads from stale buffer after interrupt
On Friday, May 31, 2024, Chet Ramey wrote: > > Thanks for the report. Since this occurs when read(2) returns a partial > buffer on an interrupt, I think we can handle it in read_builtin(). > Okay, handle how though? Leave the file offset at the last byte read before the interrupt or where the last successful read command left it? -- Oğuz
read reads from stale buffer after interrupt
See: $ while read; do :; done
Re: printf %m$ and %*m$ unimplemented in Bash, but implementated in C compilers
POSIX Issue 8 will require that this feature is supported, see https://www.austingroupbugs.net/view.php?id=1592 Perhaps a future version of Bash will have it. -- Oğuz
Re: yet another $(case ... parse bug
While you're at it take a look at this too:
true; for (( ; $? == 0; ${ ! break;} )); do uname; done
Once you run this command bash gets stuck in a state where it prints
the prompt string and reads commands but doesn't execute anything. If
you press Ctrl+C it returns to normal.
Oğuz
yet another $(case ... parse bug
See: $ bash -c 'for (( $(case x in x) esac);; )); do :; done' bash: -c: line 1: syntax error: `;' unexpected bash: -c: line 1: syntax error: `(( $(case x in x) ;; esac);; ))' This is reproducible on 5.3 alpha too. Oğuz
Re: sh vs. bash -xc 'a=b c=$a'
On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote: > Only to note that this is not portable. > The FreeBSD shell will not assign "b" to "c" for this one! Nor will NetBSD sh. This lets you swap values of two variables without using a third $ x=1 y=2 $ x=$y y=$x $ echo $x $y 2 1 And some Bourne shells expand command substitutions first $ (exit 5) $ x=$? y=`exit 10` $ echo $x 10
Re: proposed BASH_SOURCE_PATH
On Wednesday, May 15, 2024, Chet Ramey wrote:
> is it more common to have
> something like the script in somewhere/bin, files to be sourced in
> somewhere/lib, and so on?
Not sure how common but this is what makes sense. Or name sourceables
foo.sh, bar.sh and executables foo, bar so they don't clash and source with
`${BASH_SOURCE%/*}' prepended to PATH and it'll work fine.
This feature request sounded promising at first, it feels like
bike-shedding now.
--
Oğuz
Re: bug in bash
On Monday, May 13, 2024, Chet Ramey wrote: > performs the setpgid in the process forked > to run the process substitution). > Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout? Direct it from /dev/null? -- Oğuz
Re: bug in bash
On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote:
> Since the redirection fails and the cat command is never started, bash
> doesn't switch the terminal process group
It does on my computer:
554 ioctl(255, TIOCSPGRP, [554]) = 0
553 execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10 /* 30 vars */
554 +++ exited with 1 +++
But it doesn't change the process group ID of `wc' to its PID, so it
ends up in the foreground process group with bash. See:
$ cat <(bash -c 'enable setpgid; setpgid $$ $$; wc -l')
Re: Re: Re: Re: [PATCH 0/4] Add import builtin
On Sun, May 5, 2024 at 7:36 AM Matheus Afonso Martins Moreira wrote: > I certainly intend to use it as one should it be merged. If it's not you should try turning this into a loadable builtin. An `include' command that lets you selectively import variables/functions from a larger collection and namespace them, restrict commands that can be invoked to a smaller set than what a PATH search would turn up, etc. would be nice to have.
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Fri, May 3, 2024 at 6:41 PM Chet Ramey wrote: > We're only talking about interactive shells here. Non-interactive shells > have printed something like this, but including the pid, for forever: > > ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID ) Never seen this and it's ugly too. Oh well, at least it doesn't show the expanded arguments.
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Friday, May 3, 2024, Chet Ramey wrote: > > Which is more confusing? > The latter, it doesn't say what was killed. The former looks different from what `jobs' prints and is more informative so it would be nice to have in an interactive shell. Not sure how people would react if their scripts started printing that though, take more people's opinions on that please. -- Oğuz
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Thu, May 2, 2024 at 8:44 PM Chet Ramey wrote: > I'm not planning to change the text. The point is whether or not this > counts as `notification' for the purposes of the jobs list, which allows > the shell to remove the job from the list. And what change of behavior discernible by the average user is counting that as such will bring?
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Thursday, May 2, 2024, Chet Ramey wrote: > > It doesn't. In an interactive shell, while executing a command list, > every shell prints a notification if a foreground job is killed by a > signal before executing the next comamnd in the list. Nobody waits > until issuing the next prompt. The standard doesn't cover that, maybe > intentionally. > Only zsh and bosh decorate the notification like `jobs' does; others including Sun and SCO ksh88 print only a string describing the signal. I think we're talking about two different categories of notifications though; the one sent when a foreground job is killed is useful when the shell is non-interactive too, the other not so much. I don't know why the standard doesn't cover it, but if you plan to follow zsh in this I don't think that's a good idea. It's ugly and confusing. -- Oğuz
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Thu, May 2, 2024 at 6:10 PM Chet Ramey wrote: > There's no real difference between the two statements; there is a > clarification for consistency with the language in the new "Job > Control" section in Issue 8. Yeah it doesn't clarify anything and the new job control section is pointlessly detailed. Issue 7 describes how every shell does job status notifications much better in the description for `set -m': Immediately before the shell issues a prompt after completion of the background job, a message reporting the exit status of the background job shall be written to standard error. If a foreground job stops, the shell shall write a message to standard error to that effect, formatted as described by the jobs utility. In addition, if a job changes status other than exiting (for example, if it stops for input or output or is stopped by a SIGSTOP signal), the shell shall write a similar message immediately prior to writing the next prompt. This makes sense, the behavior demonstrated in OP doesn't. On Thu, May 2, 2024 at 5:17 PM G. Branden Robinson wrote: > Your choice of term puzzles me. I'd call it a "revision". Thanks for correcting and apologies for any confusion. This isn't my native language and I don't speak it outside the internet.
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Thu, May 2, 2024 at 3:55 PM Chet Ramey wrote: > A paraphrase of what? Issue 7 says this: By default, the jobs utility shall display the status of all stopped jobs, running background jobs and all jobs whose status has changed and have not been reported by the shell. And Issue 8 draft, this: By default, the jobs utility shall display the status of all background jobs, both running and suspended, and all jobs whose status has changed and have not been reported by the shell. The latter, which seems to be a paraphrase of the former, sounds as if `jobs' is supposed to report on jobs other than stopped and asynchronous ones. Which is not true, no shell does it and no one expects it.
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Wed, May 1, 2024 at 10:36 PM Chet Ramey wrote: > Sure. Then you wonder why POSIX bothered to include "and all jobs whose > status has changed and have not been reported by the shell" in the > standard. No, I think it's a botched paraphrase. Issue 7 says "By default, the jobs utility shall display the status of all stopped jobs, running background jobs and all jobs whose status has changed and have not been reported by the shell." and the description for set -m agrees; "all jobs whose status has changed and have not been reported by the shell" are background jobs terminated since the last prompt.
Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions
On Tuesday, April 30, 2024, Chet Ramey wrote: > > comsubs). I can work around this case, but I'm still interested in what > people think the general rule should be. > I don't think anyone would expect to run `jobs' and see anything but asynchronous and stopped jobs. -- Oğuz
Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.
On Fri, Apr 26, 2024 at 4:57 AM Dan Shelton wrote:
> Could you do this for the next alpha release, please?
Run `find -name Makefile -exec sed -i 's/\$[({]MFLAGS[)}]//g' {} +'
and it'll work. What's the hurry?
Re: [5.3-alpha] ">& /some/file" would fail when /some/file already exists
On Fri, Apr 26, 2024 at 1:17 AM Grisha Levit wrote: > Actually, I see this on Ubuntu 22.04 but not on macOS. On Linux, O_EXCL and RX_EXPANDED (a flag used by bash to signal that the redirection word is already expanded) has the same value. I don't know why bash doesn't clear its internal flags before calling open.
Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}
On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote: > I cannot find anything in the manual that concretely explains why bash > behaves as it does in this instance. Me neither, but the current behavior is useful. Take `while false | false; do :; done' for example, if bash reported the status of the while command in PIPESTATUS you couldn't tell which part of your condition failed. This isn't reliable when the lastpipe shell option is in effect and you have `some command | break' in your loop body but I've never seen anything like that in a real shell script.
Re: bash parallel build: make[1]: warning: -j16 forced in submake: resetting jobserver mode.
On Monday, April 22, 2024, Dan Shelton wrote: > Passing -j to submakes ist just wrong. All submakes and the parent > should be part of ONE GNU make jobserver. > Is MFLAGS used for anything other than compatibility with ancient makes? Why doesn't GNU make just strip the j flag from it? -- Oğuz
Re: Exporting functions does not expand aliases in subshells
On Thursday, April 11, 2024, Kerin Millar wrote: > > Notwithstanding, I tried declaring the same function in an interactive > instance of dash and found that the alias within the command substitution > does end up being expanded, which is in stark contrast to the behaviour of > bash. > Bash's behavior matches that of dash in POSIX mode. This is documented here in the 8th item https://tiswww.case.edu/php/chet/bash/POSIX -- Oğuz
Re: Potential Bash Script Vulnerability
On Tue, Apr 9, 2024 at 5:17 AM Robert Elz wrote: > Sure, it is possible to make a useless program like this ... > Almost all real commands use stdio to read stdin. Playing about > any more with this absurd example isn't worth the bother. The relevant > text should simply be deleted from POSIX. It is bizarre and unnecessary. Using stdio to read stdin doesn't stop you from detecting if it is connected to a file and adjusting the file offset before exit. In fact, POSIX mandates that for standard utilities in XCU 1.4 Utility Defaults, INPUT FILES section: When a standard utility reads a seekable input file and terminates without an error before it reaches end-of-file, the utility shall ensure that the file offset in the open file description is properly positioned just past the last byte processed by the utility. For files that are not seekable, the state of the file offset in the open file description for that file is unspecified. A conforming application shall not assume that the following three commands are equivalent: tail -n +2 file (sed -n 1q; cat) < file cat file | (sed -n 1q; cat) The second command is equivalent to the first only when the file is seekable. The third command leaves the file offset in the open file description in an unspecified state. Other utilities, such as head, read, and sh, have similar properties. If the shell doesn't cooperate with other utilities in this, this can happen: $ cat tst.sh echo hi sed -n 1q # Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla gravida odio # ultrices, consectetur libero eu, malesuada augue. Proin commodo faucibus ipsum # et viverra. In dictum, risus eu hendrerit rutrum, lorem diam cursus sapien, # nec mollis urna nunc non enim. Etiam at porttitor neque. Quisque elementum # orci in nisi egestas, sit amet pretium est tincidunt. Pellentesque eleifend # nec tellus eu lobortis. Praesent pharetra sed neque eleifend interdum. # # Aenean eget tincidunt sem. Etiam ac ultricies leo. Nunc tortor ante, finibus # in ullamcorper id, mattis sit amet ipsum. Etiam ac diam sem. Aenean a purus # ex. Proin tincidunt erat odio, ut suscipit purus commodo nec. Curabitur eget # ante non mi sagittis congue ac non massa. Cras tincidunt bibendum erat, ut # gravida arcu congue eu. Phasellus ex quam, blandit at interdum at, cursus eu # nisi. Nullam interdum faucibus massa at luctus. Nullam eu sapien ut mauris # eleifend pharetra sit amet quis ante. Nullam porttitor enim eros, e if false; then rm uh-oh fi $ $ busybox sh
Re: Potential Bash Script Vulnerability
On Mon, Apr 8, 2024 at 5:32 PM Robert Elz wrote: > The effect is that sharing stdin between the shell script, and other > commands (than read), is almost certainly never going to work, Why not? It works fine with other shells $ cat tst.sh cat
Re: Potential Bash Script Vulnerability
On Mon, Apr 8, 2024 at 5:58 AM Robert Elz wrote: > Shells interpret their input in much the same way, regardless of > from where it comes. Would you really want your login shell to > just collect commands that you type (possibly objecting to those > with syntax errors) but executing none of them (including "exit") > until you log out (send EOF) ? On a related note, POSIX says this: When the shell is using standard input and it invokes a command that also uses standard input, the shell shall ensure that the standard input file pointer points directly after the command it has read when the command begins execution. It shall not read ahead in such a manner that any characters intended to be read by the invoked command are consumed by the shell (whether interpreted by the shell or not) or that characters that are not read by the invoked command are not seen by the shell. So this command sh <
Re: Bug tracking
On Monday, April 1, 2024, Martin D Kealey wrote: > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > Are we building a cathedral with gatekeepers, or a bazaar > where the masses can contribute? > What's stopping masses from contributing now? All you need is an email address. And why this non-stop nagging? If you want maintainership ask for it, or is your plan boring us all to death first? -- Oğuz
Debian bug #929178: wrong trap displayed inside functions
On Tuesday, March 26, 2024, Martin D Kealey wrote: > > When forwarding incoming HTML to a text-only list, most mailing list > servers will put the hyperlinks in a footnote, so that that long links > won't obscure the text they apply to. (The better ones only do this when > text text and its hyperlink differ; if the text and its hyperlink match > (like when you have XX for any XX) then nothing is gained > by duplicating it. That would appear to be the case with this mailing > list.) > > Some mail receivers (e.g. Gmail) will convert bare text that looks like a > hyperlink back into a hyperlink, which is how you get clickable links in > the footnote. > They don't actually type those brackets then. Thanks -- Oğuz
Re: Debian bug #929178: wrong trap displayed inside functions
On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson wrote: > [1] > [1] http... I keep seeing this. Why don't you guys just paste the link?
Debian bug #929178: wrong trap displayed inside functions
On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. dash doesn't even support `x=$(trap)', which is mandated by POSIX to work; and busybox sh is a bare-bones shell for small, embedded systems. -- Oğuz
Debian bug #929178: wrong trap displayed inside functions
On Monday, March 25, 2024, Gioele Barabucci wrote: > > If a function does not set a trap, `trap` will output the command set by > the caller. This is just a cosmetic issue, the right trap will be run at > runtime. > Doesn't POSIX allow this? How else do you propose we save the trap set for an event into a variable if `x=$(trap)' stops working? -- Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Oğuz wrote:
>
> $ printf '%s\0' "${a[@]@k}" | xargs -0 jq --args -n '$ARGS.positional
> | _nwise(2) | {(.[0]): .[1]}' | jq -s add
>
On reflection, splitting by NULs in JQ is better; there is no guarantee
that xargs will always provide an even number of arguments.
--
Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Greg Wooledge wrote:
> Conceptually that looks great, but how do you avoid "Argument list
> too long" with larger inputs?
$ declare -A a=([x]=1 [y]=2)
$ printf '%s\0' "${a[@]@k}" | xargs -0 jq --args -n '$ARGS.positional |
_nwise(2) | {(.[0]): .[1]}' | jq -s add
{
"y": "2",
"x": "1"
}
--
Oğuz
Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax
On Sunday, March 24, 2024, Zachary Santer wrote:
>
> Yeah, but what can you do with @k?
It helps when reconstructing an associative array as a JSON object in JQ
$ declare -A a=([x]=1 [y]=2)
$ jq --args -n '[$ARGS.positional | _nwise(2) | {(.[0]): .[1]}] | add'
"${a[@]@k}"
{
"y": "2",
"x": "1"
}
--
Oğuz
Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell
On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: > The command in the first shell will exit after a random number of > iterations with "terminated with exit status 141". That's what every other shell does. > Regardless of the reason for the SIGPIPE, the reporter expects the loop > to carry on indefinitely (`while true; ...`). Then he should do `trap '' PIPE' before the loop. > > it is incorrect that > SIGPIPE terminates the subshell. Why?
Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi
On Sunday, March 17, 2024, tpeplt wrote: > >The texinfo version of the bash manual is missing a description of > the ‘shopt’ option ‘syslog_history’. > That must be a vendor extension, bash doesn't have such an option. -- Oğuz
Re: declare -f does not output esac pattern correctly
On Tuesday, February 27, 2024, Martin D Kealey wrote: > > I've been thinking for a while now that POSIX made a mistake when it > permitted ';;' before the closing 'esac'. > I think that decision was made before POSIX. Besides it's handy when generating case clauses on the fly, you may not always know which case is going to be the last. You may not always know that at least one clause is going to be generated either, but `case x in esac' is valid, so it's not a problem. The syntax for the case command is neat as-is. -- Oğuz
Re: [PATCH] tests/array.tests: using grep -E instead of egrep
On Monday, February 19, 2024, Lawrence Velázquez wrote: > > On what system does this happen? The proposed changes might break the > test suite on some older systems. > Agreed. Those egrep invocations can be replaced with `grep -v -e BASH_VERSINFO -e PIPESTATUS -e GROUPS' though. -- Oğuz
Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )
On Tuesday, February 6, 2024, Chet Ramey wrote: > > What's the specific request here? > That bash interpret multiline commands retrieved from command history as a whole and not run the rest of the lines as separate commands when the first line is changed. Try it yourself; run a multiline command, recall it and edit the first line to introduce a syntax error and hit enter. Does it look right? Wouldn't it be much better if the entire command were discarded? -- Oğuz
Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )
On Sunday, February 4, 2024, Zachary Santer wrote: > > While I'm making feature requests. > I want to make one too. Multiline commands retrieved from history can be short-circuited like this: $ ls x y $ echo ' > rm * > ' >z $ $ ls x y z $ echo '' rm * ' >z > ^C $ ls $ After the second invocation of `ls' I add a single quote and hit enter accidentally, and lose all my files. I wish it didn't happen -- Oğuz
Re: wait -n misses signaled subprocess
On Monday, January 29, 2024, Greg Wooledge wrote: > > Anyway... a script writer who has a basic familiarity with wait(2) and > who reads about "wait -n" will probably assume that wait -n will return > immediately if a child process has already terminated and hasn't been > "pseudo-reaped" by a previous "wait" command yet. If three children > have terminated, then the next three "wait -n" commands should return > immediately, and the fourth should block (assuming a fourth child exists). > This is the case with me. There is no point in having `wait -n' if it can't distinguish a single job terminating from multiple jobs terminating between subsequent calls. -- Oğuz
Re: cd"": Shouldn't it fail?
On Sunday, January 28, 2024, Kerin Millar wrote: > To summarise, the behaviour of bash appears to conform with the wording of > Issue 7 but it may have to change for Issue 8 or a later revision. > Yeah I think you're right. In the description of directory operand, Issue 7 says: >If *directory* is an empty string, the results are unspecified. This changes to the following in Issue 8 draft 4: >If directory is an empty string, cd shall write a diagnostic message to standard error and exit with non-zero status. Sorry for the noise. -- Oğuz
Re: cd"": Shouldn't it fail?
On Sun, Jan 28, 2024 at 5:10 PM wrote: > POSIX Programmer's Manual (cd(1p) manpage) says this: > > [9 unrelated special cases] > > 10. The cd utility shall then perform actions equivalent to the >chdir() function called with curpath as the path argument. If >these actions fail for any reason, the cd utility shall >display an appropriate error message and the remainder of >this step shall not be executed. [...] Right before that, it says in 8.c: > If, as a result of this canonicalization, the curpath variable is null, no > further steps shall be taken. which is what happens in bash, busybox sh, dash, mksh, pdksh, oksh, yash, zsh, and NetBSD sh.
Re: wait -n misses signaled subprocess
On Mon, Jan 22, 2024 at 8:13 PM Steven Pelley wrote:
>
> Hello,
> I've encountered what I believe is a bug in bash's "wait -n". wait -n
> fails to return for processes that terminate due to a signal prior to
> calling wait -n. Instead, it returns 127 with an error that the
> process id cannot be found. Calling wait (without -n) then
> returns its exit code (e.g., 143). I expect wait -n to return each
> process through successive calls to wait -n, which is the case for
> processes that terminate in other manners even prior to calling wait
> -n.
I agree that this is a bug in bash.
jobs.c/wait_for_any_jobs() marks all dead jobs as notified after
reporting the status of the first one and misses the rest. With the
following change (not a real fix, just for demonstration), devel
branch behaves as expected:
diff --git a/jobs.c b/jobs.c
index 3e68bf24..d7c8d11b 100644
--- a/jobs.c
+++ b/jobs.c
@@ -3257,7 +3257,7 @@ wait_for_any_job (int flags, struct procstat *ps)
{
if ((flags & JWAIT_WAITING) && jobs[i] && IS_WAITING (i) == 0)
continue; /* if we don't want it, skip it */
- if (jobs[i] && DEADJOB (i) && IS_NOTIFIED (i) == 0 &&
IS_FOREGROUND (i) == 0)
+ if (jobs[i] && DEADJOB (i) && IS_FOREGROUND (i) == 0)
{
return_job:
r = job_exit_status (i);
Re: ./script doesn't work in completion function
On Mon, Jan 22, 2024 at 3:25 PM Greg Wooledge wrote: > But in any case, writing a "script" without a shebang and then counting > on the shell to work around the broken script is not ideal. Unlike shebangs that behavior is standardized. Which is what I consider ideal. Thanks for your input
Re: ./script doesn't work in completion function
On Monday, January 22, 2024, Martin D Kealey wrote: > > You seem to have created an invalid executable. It seems that scripts > without a #! can only be run with help from the debugger library > Hi Martin, POSIX shells interpret such executables as shell scripts, I don't think bash would take a hacky approach like that for implementing this basic functionality. It must be something else -- Oğuz
./script doesn't work in completion function
See:
$ echo echo foo bar >s
$ chmod +x s
$ f(){ COMPREPLY=($(bash ./s));}
$ complete -F f g
$
$ g
bar foo
$ g ^C
$
$ f(){ COMPREPLY=($(./s));}
$ g ^C^C
$
I press tab after typing `g ' in both cases, this moves the cursor to
the right in the second case instead of showing the completion
options.
This is reproducible on both the devel branch and 5.1.16, I didn't test 5.2.
Oğuz
Re: nofork command substitution bugs
On Fri, Jan 12, 2024 at 7:05 PM Chet Ramey wrote:
> Nofork command substitution freezes the jobs list, because you don't
> want jobs appearing and disappearing in the list while you're running
> word expansion. If the jobs list is frozen, wait -n doesn't even try
> waiting, since you don't want jobs removed from the list in, say, a
> SIGCHLD trap. I think it's ok to do the wait but not delete the job,
> regardless of what posix says, so I'll make that change for funsubs.
Sounds good, thanks.
> Why would that be unexpected, since you're explicitly running something
> in the calling shell's context, with the expected side effects to that
> environment?
I wasn't clear. This doesn't exit the shell
bash-5.3$ exec foo
bash: exec: foo: not found
bash-5.3$
This does:
bash-5.3$ : ${ exec foo;}
bash: exec: foo: not found
$
Why would you expect either to cause an interactive shell to exit?
nofork command substitution bugs
These bugs affect the development branch only.
1. `wait -n' doesn't work inside nofork command substitution. I think
it should, or wait without `-n' shouldn't work either, or what works
and what doesn't should be documented.
$ sleep 3 & sleep 1; echo ${| wait -n -p REPLY;}
[1] 433
$
[1]+ Donesleep 3
$
2. Sending a signal other than SIGTERM to an asynchronous process
created inside nofork command substitution kills the parent shell.
This should not happen.
$ trap uname EXIT
$ : ${ dd if=/dev/zero of=/dev/null &}; sleep 1; kill -USR1 %
4730333+0 records in
4730333+0 records out
2421930496 bytes (2.4 GB, 2.3 GiB) copied, 1.00056 s, 2.4 GB/s
Linux
User defined signal 1
$
There are other cases where the parent shell exits unexpectedly, such
as when the exec command fails inside nofork command substitution, but
I'm not sure if those are bugs or intended behavior.
3. Linking REPLY to a variable inside nofork command substitution
renders the target variable unset. I don't think this should be the
case; and if it has to, it should be documented.
$ x=y
$ echo ${| declare -n REPLY=x;}
y
$ declare -p x
bash: declare: x: not found
$
inconsistent handling of closing brace inside no-fork command substitution
See:
$ ${ case } in }) echo uname; esac }
Linux
$ ${ case }x in }x) echo uname; esac }
bash: command substitution: line 25: syntax error near unexpected token `x'
bash: command substitution: line 25: `}x)'
$ ${ case }x in \}x) echo uname; esac }
Linux
$
I don't think this should be a syntax error because the closing brace
is not in a place it can terminate the command substitution.
Oğuz
Re: A feature request regarding redirection to variables
On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote:
>
> A very common thing I need to do when writing bash is to collect both
> the stdout and stderr of a command. This can be done relatively
> reasonably with files but it would be very attractive to be able to
> redirect these directly to a variable some how.
The new no-fork command substitution feature already allows this:
$ f(){ echo foo; echo bar >&2;}
$ a=${ { b=${ f;};} 2>&1;}
$ declare -p a b
declare -- a="bar"
declare -- b="foo"
You just need to wait for the next release
Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, Koichi Murase wrote: > > In that case, a question would be what would be the standard way to > specify the Bash-specific variable, > There doesn't have to be a standard way; I'd set it in ~/.profile, you'd set it wherever is convenient on your setup.
Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, jidanni wrote: > Maybe on the list of config files bash looks at, > there should be also .config/bash/... as that is > the trend these days... > Trends come and go. If there is demand for this feature bash should do it by honoring an environment variable like BASH_HOME when looking for rc files instead of exploring a fixed path. -- Oğuz
Re: Missing documentation "-bash_input"
On Wednesday, November 29, 2023, Klaus Frank wrote: > One thing though, I probably should already know that, but why is a $0 > needed even though a command was already specified? Shouldn't the command > itself be $0? No, $0 is used in error messages: $ bash -c '"' foo foo: -c: line 1: unexpected EOF while looking for matching `"' $ You wouldn't want the entire script printed for every error. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Do you mean something like a "fork_noreparent" builtin that would call > make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the > child would have to call ? > I don't have a preference for either. I oppose it being a shell option because first, it's a single function call that works on only one target platform; and second, its effect doesn't seem to stick. If I'm not missing anything, if I enable the proposed noreparent option in a shell and run a command, and that command forks, its children won't receive the death signal when the shell dies. It doesn't make any sense. Unless there is a way to make it stick and affect all descendants of the shell process, I don't think this would be very useful as a loadable builtin either. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov > 2023 16:05:38 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 Patch > Level: 21 > Release Status: release > > Description: > Hi, > > I would like to suggest a new shell option to ensure child processes are > automatically killed when the parent dies. > > Right now, it's already possible to emulate this feature by setting a trap > to kill all child processes on exit (trap "kill 0" EXIT), but obviously it > doesn't work if the process is terminated by a signal that cannot be caught > (like SIGKILL). > > On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate > the parent termination signal to the child, regardless of whether the > signal can be caught or not. > > The rationale for this feature is that scripts spawning background > processes to listen to various events (udev events, window manager events, > etc) often leave orphan processes behind when terminated forcefully. > > I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Re: Idea: jobs(1) -i to print only :%ID:s
On Thursday, November 9, 2023, Steffen Nurpmeso wrote:
>
> I mean some scripting on "jobs | wc -l" would do that, though. :(
> Maybe i should just write a function that builds the string
> necessary to do what i wanted with %* or "%1-2 %4" etc.
> Eh. Forget about it.
>
Can't you abuse jobs -x somehow? Like this perhaps
jobs -x printf '%s\n' %{1..100} | awk '!/%/{print "%"NR}'
--
Oğuz
Re: Defaults when cross-compiling
On Tuesday, November 7, 2023, Chet Ramey wrote: > > It's interesting that musl supports brk but not sbrk It doesn't support locales either. I always assumed it's someone's toy project but looks like there are Linux distros shipping it instead of glibc. Huh -- Oğuz
Re: test -lt inconsistent about white space
On Sun, Oct 29, 2023 at 8:49 AM Paul Eggert wrote: > My understanding is that Bash was intended to allow both leading and > trailing whitespace. This is compatible with ksh and with Dash. If > that's the intent, Bash should be consistent about it, just as ksh and > Dash are. There seems little point to allowing one nonempty set of > whitespace characters before the integer, and a different nonempty set > of whitespace characters afterwards. legal_number was isint, which skipped both leading and trailing space using the whitespace macro. See here: https://git.savannah.gnu.org/cgit/bash.git/tree/test.c?id=726f63884db0132f01745f1fb4465e6621088ccf#n354 I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this.
Re: test -lt inconsistent about white space
On Saturday, October 28, 2023, Paul Eggert wrote: > Bash should treat trailing whitespace the same way it treats leading > whitespace, Why? The same commands fail on bosh, yash, and zsh too. -- Oğuz
