On December 29, 2024 3:50:36 PM EST, "Lawrence Velázquez"
wrote:
>On Sun, Dec 29, 2024, at 3:44 PM, Daniel Colascione wrote:
>> I wonder whether it would be possible to add a simple catch-all command
>> that would encompass a set of options that can't be def
I wonder whether it would be possible to add a simple catch-all command
that would encompass a set of options that can't be defaults but that
make writing shell scripts easier, e.g. set -euo pipefail, nullglob,
inherit_errexit, extglob, assoc_expand_once, and various other settings.
It's annoying
Greg Wooledge writes:
> On Tue, Jul 09, 2024 at 20:14:27 +, Erik Keever wrote:
>> A --debug-envvars flag which will, when passed to bash, catch every
>> time an environment variable is set and print the file/line that is
>> setting it. To restrict it, "--debug-envvars FOO,BAR" to catch only
>
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 convinc
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 exten
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 trap
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 s
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" a
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 unbu
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 functio
> 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} p
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 e
> 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 com
> 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 smal
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 re
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
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 o
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
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 "standout", and us
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 smart
, 2018 7:05 PM, "Clark Wang" wrote:
> On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione
> wrote:
>
>> 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
>>
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
stores
On 10/15/2016 12:23 AM, L. A. Walsh wrote:
Daniel Colascione wrote:
One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
has an old-fashioned non-COW fork, and to add insult to injury,
process creation generally is very slow (~100ms). It pays to eliminate
su
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 anyt
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?
signatu
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
> ter
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 readli
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
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
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 inse
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 e
Consider the string "word1 word2 word3 word4 word5" with point just
before "word3". In bash-4.1, shell-backword-word moves point to the
beginning of the string, but shell-forward-word just advances to the end
of word4. The two functions really should be symmetric --- either both
should break out of
40 matches
Mail list logo
