On 10/11/15, isabella parakiss wrote:
> In posix mode, bash replaces ! in my PS1 with the history number.
>
> $ PS1=' ! '
> ! set -o posix
> 513 exit
>
> It doesn't happen with any other prompt escape sequence, afaict.
> This looks... intentional? WTF?
>
Ok I've now read this page: http://tisw
In posix mode, bash replaces ! in my PS1 with the history number.
$ PS1=' ! '
! set -o posix
513 exit
It doesn't happen with any other prompt escape sequence, afaict.
This looks... intentional? WTF?
---
xoxo iza
Chet Ramey wrote:
On 10/10/15 4:19 PM, Linda Walsh wrote:
Chet Ramey wrote:
On 10/9/15 2:42 PM, Ian Jackson wrote:
However, it would be very easy for bash to provide an option (via `set
-o' perhaps) to disable this behaviour. That is, to allow SIGINT to
be delivered normally to child proces
isabella parakiss wrote:
$ a= read a <<< x # this creates a variable in the current shell
$ declare -p a
declare -- a="x"
$ b= mapfile b <<< x# this doesn't
$ declare -p b
bash: declare: b: not found
Very good point... more interesting is adding posix mode
to the mix:
#
$ a= read a <<< x # this creates a variable in the current shell
$ declare -p a
declare -- a="x"
$ b= mapfile b <<< x# this doesn't
$ declare -p b
bash: declare: b: not found
Other shells don't seem to agree on what should happen in this case, but
it'd be nice to have a more consistent
On 10/10/15 4:19 PM, Linda Walsh wrote:
> Chet Ramey wrote:
>> On 10/9/15 2:42 PM, Ian Jackson wrote:
>>>
>>> However, it would be very easy for bash to provide an option (via `set
>>> -o' perhaps) to disable this behaviour. That is, to allow SIGINT to
>>> be delivered normally to child processes.
Chet Ramey wrote:
On 10/9/15 2:42 PM, Ian Jackson wrote:
However, it would be very easy for bash to provide an option (via `set
-o' perhaps) to disable this behaviour. That is, to allow SIGINT to
be delivered normally to child processes.
I'm restricting non-standard options to `shopt' to avo
On 10/9/15 8:17 AM, Linda Walsh wrote:
>
>
> There are several problems with how type -P returns errors.
`type -P', and `type' in general, reflects what would happen when a name is
used as a command.
> 1) if a file isn't executable, type returns it anyway in
>> ls -l /sbin/scat
> -r--r--r-- 1
On 10/9/15 2:42 PM, Ian Jackson wrote:
> Hi.
>
> I've been wrestling recently[1] with a bash script which invokes a
> number of subprocesses in parallel and collects the output. The
> problem is that if you ^C the script, the subprocesses carry on
> running. This is because of the standards-mand
On 10/9/15 9:14 PM, 積丹尼 Dan Jacobson wrote:
> # dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4. shows
> phpmyadmin_4%3a4.4.15-1_all.deb phpmyadmin_4%3a4.5.0.2-2_all.deb
> # dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4.
>
> Can you please make the first different character bold, like emacs
On 10/8/15 2:36 PM, Christoph Gysin wrote:
>> I think you're overlooking what I referred to above: that the exit status
>> of a command substitution doesn't have any effect on whether the parent's
>> command succeeds or fails except in one case: the right-hand-side of an
>> assignment statement tha
On 10/10/15 9:36 AM, Carlos Pita wrote:
> Hi Chet,
>
> consider the following program:
>
> yyy() {
> continue
> }
>
> xxx() {
> while true; do
> echo x
> yyy
> echo y
> break
> done
> }
>
> xxx
>
> In the bash devel branch it will ignore the continue and echo
>
> x
> y
Hi Chet,
consider the following program:
yyy() {
continue
}
xxx() {
while true; do
echo x
yyy
echo y
break
done
}
xxx
In the bash devel branch it will ignore the continue and echo
x
y
In the stable branch it will echo
x
x
x
x
.
.
.
forever, because the continue works
13 matches
Mail list logo
