Re: why must bash zap last search string just because we hit ^C?

> "DR" == Dave Rutherford writes: DR> Can you run gnu screen? ^A-c will get you a new shell session in the DR> existing terminal emulator (it will use a new terminal device, though, DR> if that's what you care about.) Let's pretend that I am on a gunk device on a gunk OS and all I have to wo

Re: why must bash zap last search string just because we hit ^C?

> "CFAJ" == Chris F A Johnson writes: CFAJ> ^Z then fg ^Rsearch_string^Z^Z^Z^Z the ^Z's are ignored. I can't get back to a prompt with ^Z.

Re: why must bash zap last search string just because we hit ^C?

On Sat, Oct 17, 2015 at 11:19 PM, 積丹尼 Dan Jacobson wrote: > > "DW" == Dennis Williamson writes: > > DW> Or just open a new terminal rather than interrupting an in-progress > search. > > I am on a device where opening a new terminal is a lot of trouble. > Can you run gnu screen? ^A-c will ge

Re: why must bash zap last search string just because we hit ^C?

On Sun, 18 Oct 2015, 積丹尼 Dan Jacobson wrote: "CFAJ" == Chris F A Johnson writes: CFAJ> Or just press UP (as many times as necessary) and RET. That won't get me to a $ prompt. I want to suspend my search and resume it later. ^Z then fg -- Chris F.A. Johnson,

Re: why must bash zap last search string just because we hit ^C?

> "DW" == Dennis Williamson writes: DW> Or just open a new terminal rather than interrupting an in-progress search. I am on a device where opening a new terminal is a lot of trouble.

Re: why must bash zap last search string just because we hit ^C?

On Oct 17, 2015 9:06 PM, "積丹尼 Dan Jacobson" wrote: > > DW> On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote: > > DW> ^C rudely aborts the entire operation. Why assume you want to save any > DW> of the context? > > Because I got a phone call: the boss asked me to execute a shell > comman

Re: why must bash zap last search string just because we hit ^C?

> "CFAJ" == Chris F A Johnson writes: CFAJ> Or just press UP (as many times as necessary) and RET. That won't get me to a $ prompt. I want to suspend my search and resume it later.

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

On Sat, Oct 17, 2015 at 05:43:15PM -0700, Linda Walsh wrote: > [cut] > from a semantic point of view, how is: > >readarray foo < <(cat /etc/passwd) > > different from > >shopt -s lastpipe >cat /etc/passwd |readarray foo > > Is there something in the semantics that would require the

Re: why must bash zap last search string just because we hit ^C?

On Sun, 18 Oct 2015, 積丹尼 Dan Jacobson wrote: DW> On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote: DW> ^C rudely aborts the entire operation.  Why assume you want to save any DW> of the context? Because I got a phone call: the boss asked me to execute a shell command. I used ^C to ge

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

On Sat, 17 Oct 2015, Linda Walsh wrote: Chet Ramey wrote: On 10/16/15 7:52 PM, Linda Walsh wrote: As I mentioned, my initial take on implementation was using standard pipes instead of named pipes (not having read or perhaps having glossed over the 'named pipes' aspect). I think you're missin

Re: why must bash zap last search string just because we hit ^C?

DW> On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote: DW> ^C rudely aborts the entire operation.  Why assume you want to save any DW> of the context? Because I got a phone call: the boss asked me to execute a shell command. I used ^C to get myself back to a prompt so I could type in the

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

Chet Ramey wrote: On 10/16/15 7:52 PM, Linda Walsh wrote: As I mentioned, my initial take on implementation was using standard pipes instead of named pipes (not having read or perhaps having glossed over the 'named pipes' aspect). I think you're missing that process substitution is a word e

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

On 10/16/15 7:52 PM, Linda Walsh wrote: > As I mentioned, my initial take on implementation was > using standard pipes instead of named pipes (not having read > or perhaps having glossed over the 'named pipes' aspect). I think you're missing that process substitution is a word expansion that is d

Re: problem with @A and arrays

On 10/16/15 8:55 PM, isabella parakiss wrote: > ${array[@]@A} splits the values. > > $ a=("ab" "c d"); printf "<%s>" "${a[@]@A}" > <-a><[1]="c> Thanks for the report. This will be fixed in the next bash release. (BTW, your patch does not result in a valid declare command with a correct com

Re: language inconsistency(wart) & RFE

isabella parakiss wrote: Maybe you can just use this?alias declare='declare -g' If I needed a way to declare something global, yes... But what I am wanting is a way to allow changing the defaults of the implicit variable creation (which could still be explicitly declared with