On 1/25/21 11:59 AM, Greg Wooledge wrote:
On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote:
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
declare -A copy
eval copy=( "${assoc[@]@K}" )
So many reputable people contributed to the demonization of `eval' that I
don't think I can
On 1/22/21 9:54 AM, Saint Michael wrote:
I vote for this new feature.
Personally, I've found that scanf underpowered for parsing modern data
formats. Bash's existing regular expression support seems perfectly
adequate to me, and it can handle everything that scanf can. I'd only
suggest
On 11/21/20 1:15 PM, Chet Ramey wrote:
On 11/21/20 2:32 PM, Andreas Schwab wrote:
On Nov 21 2020, Chet Ramey wrote:
but since the shell always ignores SIGTERM,
Even a non-interactive shell?
No, you're right, it's SIGQUIT the shell always ignores. It catches SIGTERM
if there is an EXIT
On September 30, 2020 8:44:40 AM Andreas Schwab wrote:
On Sep 30 2020, Daniel Colascione wrote:
It might be worth asking lkml to lift this restriction
You will have bad luck with that. The limit has been introduced for
security reasons.
What "security reasons"? You'd still
On September 30, 2020 8:24:01 AM Ilkka Virta wrote:
On Wed, Sep 30, 2020 at 5:53 PM Michael Green wrote:
The included short script when run with the following command results
in execve "E2BIG (Argument list too long) errors".
* The number of arguments can be tuned down to "seq 1 23694"
On April 22, 2020 6:32:07 PM wor...@alum.mit.edu (Dale R. Worley) wrote:
The crux of the problem, IMHO, is to look at it from the right angle:
Occasionally, the user desires that I/O through certain pipes should be
unbuffered, that is, the stdio stream(s) that write into the pipe should
be
On 4/23/20 4:39 PM, Dale R. Worley wrote:
Andreas Schwab writes:
See stdbuf(1).
The limitation(s) of stdbuf are: It can only be applied to the standard
I/O streams. It doesn't affect statically-linked executables. It only
applies to a single executable, so if the command is a shell
> On 2020-04-11 at 18:04 +0200, gentoo_eshoes wrote:
>> $ echo ${PS1@A}
>> declare -x PS1=$'\\\n---\\n\\\n\\[\\a\\]\\\n\\[\\e[1;37m\
>> \e[42m\\]\\u@\\H\\[\\e[0m\\] \\\n\\[\\033[1;30m\\]$(date "+%Y/%m/%d %
>> H:%M:%S")\\[\\033[0m\\] \\\n\\[\\e[0;37m\\]\\s\\V t:\\l j:\\j \\\nd:
>> ${SHLVL}
On 4/12/20 6:23 PM, Chet Ramey wrote:
On 4/12/20 2:15 PM, gentoo_esh...@tutanota.com wrote:
There is one more/different 'face' issue: if I paste a line and then press
Enter (as opposed to any alphanumeric key or arrow keys) then the highlight
remains(highlighted), possibly because the ^M is
> I keep on wondering why these shells can't come up with something better
> than improving previous shell syntax by little by only providing poor
> better alternatives.
> I somehow think there is a need to rethink shells from scratch to make
> them
> less mentally demanding and readable in the
> On 3/25/20 1:14 PM, Daniel Colascione wrote:
>
>> Ping? Anything I can do to help?
>
> OK, I sat down and looked at this code, since I'm homebound. I added the
> active mark/region features (rl_activate_mark/rl_deactivate_mark/etc.)
> and a couple of the smaller p
On Fri, Jan 10, 2020 at 5:34 AM Chet Ramey wrote:
>
> On 1/8/20 2:38 PM, Daniel Colascione wrote:
> > On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione
> > wrote:
> >>
> >> On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote:
> >>>
> >>>
> Date:Mon, 24 Feb 2020 06:44:12 -0800
> From: "Daniel Colascione"
> Message-ID:
>
> | That executing traps except in case you lose one rare race is
> painfully
> | obvious.
>
> Maybe you misunderstand the issue, no traps are l
> Date:Mon, 24 Feb 2020 04:58:31 -0800
> From: "Daniel Colascione"
> Message-ID: <07d1441d41280e6f9535048d6485.squir...@dancol.org>
>
> | That is a poor excuse for not fixing bugs.
>
> Only if they are bugs.
That executing t
> There are lots of programming languages around, they each have their
> particular
> niche - the reason their inventors created them in the first place. Use
> an
> appropriate one, rather than attempting to shoehorn some feature that is
> needed
> into a language that was never intended for it
On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione wrote:
>
> On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote:
> >
> > On 9/23/19 7:32 AM, Daniel Colascione wrote:
> > > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote:
> > >>
> > >> On 1
On 12/26/19 7:37 AM, Eric S. Raymond wrote:
In attempting to use GNU parallel, with some bash scripts, I
discovered I had a problem with tempfile collisions due to
all of the thread having the same PID.
I was able to come up with a workaround, but...
RFE: bash should have a TID varuable that
On Thu, Nov 7, 2019 at 12:09 PM Chet Ramey wrote:
>
> On 11/5/19 12:49 PM, Daniel Colascione wrote:
> > Right now, bash history saves only the command line actually executed.
>
> This isn't quite the case. What it saves is the line returned from
> readline, before it's expand
Right now, bash history saves only the command line actually executed.
Why not also, optionally, save command execution times and exit
statuses? This information is practically free to collect.
On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote:
>
> On 9/23/19 7:32 AM, Daniel Colascione wrote:
> > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote:
> >>
> >> On 1/9/19 2:39 PM, Daniel Colascione wrote:
> >>> Any chance we can revive this patch now t
On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote:
>
> On 1/9/19 2:39 PM, Daniel Colascione wrote:
> > Any chance we can revive this patch now that Bash 5 is out? (The patch
> > itself, of course, would need to be rebased.)
>
> Yes, I plan to.
Have you had a chance to look at the patch?
Any chance we can revive this patch now that Bash 5 is out? (The patch
itself, of course, would need to be rebased.)
On Fri, Jun 8, 2018 at 9:27 AM Chet Ramey wrote:
>
> On 6/7/18 10:45 PM, Daniel Colascione wrote:
> > Hey. I'd appreciate a quick peek at this patch. The lack of vis
Hey. I'd appreciate a quick peek at this patch. The lack of visual feedback
on paste is leading people to turn off bracketed paste mode, which is
unfortunate.
On Mon, Mar 19, 2018 at 11:06 AM, Chet Ramey wrote:
> On 3/19/18 1:25 PM, Daniel Colascione wrote:
> > Ping
>
> I
Ping
On Fri, Mar 9, 2018 at 11:50 PM, Daniel Colascione <dan...@google.com>
wrote:
> This patch teaches readline about two concepts from Emacs: 1) faces,
> and 2) the mark being "active". Both exist in rudimentary form: we
> support exactly two faces, normal and &qu
This patch teaches readline about two concepts from Emacs: 1) faces,
and 2) the mark being "active". Both exist in rudimentary form: we
support exactly two faces, normal and "standout", and use standout to
highlight the contents of the region when the mark is active. Readline
redisplay is now
, 2018 7:05 PM, "Clark Wang" <dearv...@gmail.com> wrote:
> On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione <dan...@google.com>
> wrote:
>
>> Right now, PROMPT_COMMAND gives a shell command to run before displaying
>> the prompt. It's common these
Right now, PROMPT_COMMAND gives a shell command to run before displaying
the prompt. It's common these days to include in one's bash configuration
numerous packages from different sources that *all* want to run code at
PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
On 10/13/2016 08:05 PM, Bob Proulx wrote:
XiaoBing Jiang wrote:
Greg Wooledge wrote:
If you want to ENSURE that the child shell process is replaced by the
external sleep 20, use an explicit exec.
yes, I want to know why bash not optimize this. or any strategy ?
Because it wouldn't save
Consider this command:
foo $'foo \' bar'
As far as the bash core is concerned, this command has one argument
word. But readline, for completion, splits it up into three words:
0: foo
1: $'abc \'
2: bar'
Shouldn't we be splitting the command line into the same number of words?
On 02/15/2015 01:48 PM, Chet Ramey wrote:
On 2/13/15 12:19 PM, Pádraig Brady wrote:
I was expecting bash to handle SIGPIPE specially here,
as in this context it's informational rather than an indication of error.
I don't agree. It's a fatal signal whose default disposition is to
terminate
On 10/29/2014 08:49 PM, Chet Ramey wrote:
On 10/27/14, 6:35 PM, Daniel Colascione wrote:
This patch adds support for bracketed paste mode to readline. In
this mode, readline instructs the terminal to wrap pasted strings in
special control sequences so that programs can distinguish them from
On 11/06/2014 02:38 AM, Chet Ramey wrote:
On 11/5/14 9:02 PM, Daniel Colascione wrote:
On 10/29/2014 08:49 PM, Chet Ramey wrote:
On 10/27/14, 6:35 PM, Daniel Colascione wrote:
This patch adds support for bracketed paste mode to readline. In
this mode, readline instructs the terminal to wrap
On 10/30/2014 06:05 AM, Bob Proulx wrote:
Daniel Colascione wrote:
Well, I don't know whether Chet left the feature enabled by
default. I hope he did, though, since preventing execution of pasted
commands is one of the feature's key benefits. In bash, you should
be able to execute a pasted
On 10/29/2014 09:35 PM, Pádraig Brady wrote:
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer
This patch adds support for bracketed paste mode to readline. In
this mode, readline instructs the terminal to wrap pasted strings in
special control sequences so that programs can distinguish them from
typed input. This patch makes readline insert each pasted string as
one big literal into the
35 matches
Mail list logo
