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
>
The message ID with the patch in question was of course
<87leasmvoo@oldenburg.str.redhat.com>
--
Daniel
lublin.se
Maybe some compiler change triggered this now.
--
Daniel
lublin.se
On November 18, 2023, Greg Wooledge wrote:
>On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the
>GNU Bourne Again SHell wrote:
>> echo foo | tee >(xclip -i) | tr o x
>>
>> The command does print "fxx" but then it hangs.
>>
>> The same command behaves correctly when run
These are both very useful!
On Thu, Feb 16, 2023 at 6:31 PM Daniel Douglas wrote:
>
> On Thu, Feb 16, 2023 at 2:42 PM Greg Wooledge wrote:
> >
> > On Thu, Feb 16, 2023 at 07:21:14PM -, Syed Maaz wrote:
> > > Hey Team,
> > >
> > > I am a security researcher,I have fo
On Thu, Feb 16, 2023 at 2:42 PM Greg Wooledge wrote:
>
> On Thu, Feb 16, 2023 at 07:21:14PM -, Syed Maaz wrote:
> > Hey Team,
> >
> > I am a security researcher,I have found this vulnerability related to
> > your website bash-hackers.org.
>
> Just for the record, "bash-hackers.org" is
> Of course, all mention of aliases should really be removed from
> POSIX - aliases are even worse than "set -e".
It should be removed because the spec is full of inaccuracies and isn't
useful. People that know enough to define the standard properly have
other priorities clearly. I think many of u
move them outside the top level function, but I don't know if
it would get in the way for some people doing more convoluted stuff
with functions.
From: [1]Chet Ramey
Sent: Wednesday, 5 October 2022 20:22
To: [2]Daniel Castro; [3]bug-bash@gnu.org
Cc: [4]chet.ra...@case.edu
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses
Thanks for your tips, a lot learned.
Greg Wooledge 于2022年2月16日周三 20:47写道：
>
> On Wed, Feb 16, 2022 at 04:10:40PM +0800, Daniel Qian wrote:
> > FOO=$(cat /tmp/foo.txt)
> > got_md5=$(echo "$FOO" | md5sum -b | cut -d ' ' -f 1)
>
> In addition to what ot
I'm not familiar with Bash version/release policy, I only found 5.1.8,
5.1.12, 5.1.16 at
download page https://ftp.gnu.org/gnu/bash/
Is this fix included in 5.1.16 version?
Chet Ramey 于2022年2月16日周三 21:59写道：
>
> On 2/16/22 3:10 AM, Daniel Qian wrote:
> > Hi all,
> >
>
ail, compare it
with `foo.txt`,
found that a random byte are inserted into multiple positions.
I created a github repo for this issue, all the scripts are there:
https://github.com/chanjarster/bash-5_1_8_long_var_corrupt
--
Daniel Qian
Apache Committer(chanjarster)
blog：https://chanjarster.githu
On Fri, Apr 23, 2021 at 10:43 AM john wrote:
> From: john
> To: bug-bash@gnu.org
> Subject: ls dumps bash
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
27;t performed quote removal still
is so that's no help in this regard.
I wonder if this particular point, how to check an arbitrary array key
exists or not, is documented anywhere yet? I'd be happy to send a
patch. Can someone point me to the sections in the man{ual,page} that could
use commentary for this?
Thanks,
Daniel
f ${!array[*]}.
Do you think this intended behaviour or a real bug?
Tested on Debian buster, with bash_5.0-4 ($BASH_VERSION="5.0.3(1)-release")
and git master commit 76404c85d492c001f59f2644074333ffb7608532.
Thanks,
Daniel
PS: Please keep me in CC as I'm not subscribed.
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 Sun, Oct 11, 2020 at 12:59 PM Chet Ramey wrote:
>
> On 10/9/20 7:23 PM, Daniel Farina wrote:
>
> > Bash Version: 5.0
> > Patch Level: 17
> > Release Status: release
> >
> > Description:
> >
> > Pressing Ctrl-C during any subshell evaluation t
Configuration Informatio:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/u
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 27/7/20 22:09, Chet Ramey wrote:
> On 7/25/20 12:21 PM, Daniel Molina wrote:
>> Hi,
>>
>> I found some aspects of readline documentation that seem inconsistent to
>> me and I wanted to share them.
>>
>> 1. The difference between backward-kill-line and
ne
3. Key-bindings in the emacs/vi list are written with capital letters
(C-A), but not in the section with the description (C-a).
Best regards,
Daniel
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
Hello,
Is the following an intended behavior? Undefined? A bug?
$ a[1]=2; declare -n ref=a[1]; echo $ref $((ref))
2 0
Thanks,
Daniel
> 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.
the use of the "…" character results in the ability to delete the bash prompt
string using backspace
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?
On Mon 2019-04-15 17:35:49 -0400, Chet Ramey wrote:
> I'll probably release a patch, yes. In the meantime, distributions are free
> to take the change and apply it to their versions.
Thanks for the followup! I've updated https://bugs.debian.org/920455
with the appropriate details.
--dkg
On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
> It's an easy change. See the attachment.
Thanks! The attached patch removed a comment and changed an #if 1 to
#if 0, but i think the comment change is just a cleanup reflecting the
previous state of the codebase. Is that right?
> I agree tha
On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote:
> But the execs mean that the shell that is eventually invoked to run the
> `wait' is the parent of the process substitution. So the subshell has
> children, whether or not it has run the process substitution itself.
Yes, agreed. This is the sit
Over in the "here strings and tmpfiles" thread, a distraction came up,
which i'm splitting out into a separate thread. Please don't conflate
the two, i'm just looking for further clarity about process
substitutions and the wait builtin.
dkg and chet wrote:
https://bugs.debian.org/920455
>>>
On Thu 2019-04-11 10:04:02 +0200, Andreas Schwab wrote:
> On Apr 10 2019, Daniel Kahn Gillmor wrote:
>
>> data written to the local filesystem can be discovered by someone
>> analyzing the disk controller data path, or by someone with access to
>> the underlying storage
On Wed 2019-04-10 16:16:44 -0400, Chet Ramey wrote:
> Is it just that people have not realized all along that most shells,
> certainly all historical shells, that implement here documents use temp
> files to do it? It's really only the ash-based shells (not an insignificant
> portion of the shells
On Wed 2019-04-10 09:07:27 -0400, Chet Ramey wrote:
> On 4/9/19 2:56 AM, Jason A. Donenfeld wrote:
>> Since originally raising this issue with dkg (leading to this email
>> thread), I've only followed along from a bit of a distance. But it does
>> look like there's been some good progress: there's
On Tue 2019-03-19 09:31:55 -0400, Greg Wooledge wrote:
> There are scripts that *rely* on the seekability of the temporary files
> created by here-documents and here-strings. "Improving" the "situation"
> would break backward compatibility.
i hope you noticed that of my suggested improvements, on
On Tue 2019-03-19 08:25:50 -0400, Greg Wooledge wrote:
> On Mon, Mar 18, 2019 at 05:18:10PM -0400, Daniel Kahn Gillmor wrote:
>> strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'
>> It turns out that this creates a tempora
Thanks for the feedback, Eduardo--
On Mon 2019-03-18 17:40:17 -0700, Eduardo A. Bustamante López wrote:
> I don't think the implementation details of herestrings are documented
> anywhere,
> and I'm not too sure if they should (i.e. IMO if you need that degree of
> control
> over the implementat
On Mon 2019-03-18 17:18:10 -0400, Daniel Kahn Gillmor wrote:
> A few possible options for trying to improve the situation:
>
> a) use socketpair(2) or pipe(2) instead of making a tmpfile. this has
> the potential downside that the semantics of access to the remaining
>
hi bash developers--
I ran the following command to get a sense of how bash deals with here
strings under the hood:
strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'
(i'm testing with bash 5.0-2 on debian testing/unstable).
It turns out that this creates a temporary fil
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
On Sun, Dec 30, 2018 at 8:37 PM mike b wrote:
> Configuration Information:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/sh
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'
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
On Mon, Apr 2, 2018 at 5:16 PM, PRussell
wrote:
>
> echo 4B
> ( set -x;var=5;var1=var; (( var1 == $var2 )) && echo yes || echo no )
>
>
> It appears that 3A and 4A evaluate to 0 because of the arithmetic context.
> 3A echo's yes; 4A echo's no.
>
> The problem is what is happening with 3B and 4B
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 Tue, Oct 17, 2017 at 1:37 PM, Ángel wrote:
> bash converts < <( dd_need_io "$if" "$of" ...) into a read
> from /dev/fd/62 in order to make readarray read file descriptor 62.
>
> Given that this the host OS doesn't provide them, the first thing I
> would verify would be: is cygwin, as setup
The '[:' may be messing with it, 'a[[:alpha:]:abm[]' should work. It won't
match 'amm' because the range only matches a single character, you'd need
'a+([[:alpha:]:abm[])'
On Tue, May 16, 2017 at 10:49 AM, Eduardo Bustamante
wrote:
> On Tue, May 16, 2017 at 2:48 AM, Zoltán Herczeg
> wrote:
> >
On Mon, Mar 27, 2017 at 8:32 AM, Torka Noda wrote:
> For any particular reason?
>
> Why are they not all made available anyway? with an alternative
> array for the arguments sent to the commands fed to Bash stdin
> with "-s", so we don't have to handle all possible arguments if
> we just want the
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DL$
uname output: Linux udontknowme 4.4.
Awesome, thanks for this tip!
On Wed, Dec 7, 2016 at 8:44 AM Greg Wooledge wrote:
> On Wed, Dec 07, 2016 at 12:56:00AM +0000, Daniel Einspanjer wrote:
> > echo The desired output is:
> > echo "var = \"test test\""
>
> imadev:~$ q=\"
> imadev:~
echo ${VARIABLE:+var = '"'$VARIABLE'"'}
I tried a couple of variants of \x22 and $'\x22', but I wasn't sure about
the syntax.
Here is the only thing I have found so far that does work:
${VARIABLE:+var = $(echo '"')$VARIABLE$(echo '"')}
EOF
-Daniel
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
You are correct:
/usr/bin/\[ --help
gives the desired output.
When I ran 'which [' it stated that the /usr/bin/[ was what was running,
and so I presumed it was in bash.
Also, the error message says 'bash'
So, all in all, a bit counfusing.
Cheers,
Daniel
On 22 Sep
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
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
Are you shure?
Debian's bash includes patches up to bash42-037, which is dated 16-Jul-2012 17:20.
But the error still appears.
Gesendet: Donnerstag, 18. Dezember 2014 um 15:02 Uhr
Von: "Chet Ramey"
An: "Lars-Daniel Weber" , bug-bash@gnu.org
Cc: chet.ra...@case.
g, 18. Dezember 2014 um 08:52 Uhr
Von: "Eduardo A. Bustamante López"
An: "Lars-Daniel Weber"
Cc: bug-bash@gnu.org
Betreff: Re: bug with German umlauts
Did you test against the current development version?
I'm not seeing that in 4.3:
dualbus@hp ~ % bash --version
GNU b
-Daniel
dstart,cursorposition,(mode&CONVERTBACKSLASH?quotechars(expandedcompletion):expandedcompletion));"
This was sent here as suggested by your bug reporting under the guise of
"philosophical bugs".
Thank you for your consideration,
(I'll probably fix this myself someday, but i
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
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
export _ave=$(cat
"$type"_"$simulation"_"$from_year"_"$to_year"_"$variable"_areaaverage.txt|grep
-v Col|head -n 1|sed 's/ //g')
works fine ...
Repeat-By:
A number in the beginning of the name generates this problem
Fix:
't have any knowledge of the inner workings of parser.y let alone
how to use it or how bash interacts with it - I just happened to have
found the right place to hook into...do you have an idea how to cover these?
Thanks
Daniel
>From 698c8ae89e1bbea8d047d48c66067b09e0c38dc9 Mon Sep 17 00:00:
t - I just happened to have
found the right place to hook into...do you have an idea how to cover these?
Thanks
Daniel
>From 698c8ae89e1bbea8d047d48c66067b09e0c38dc9 Mon Sep 17 00:00:00 2001
From: Daniel Reichelt
Date: Sun, 31 Mar 2013 15:08:49 +0200
Subject: [PATCH 1/2] add flag 'N'
Chet,
2012/7/13 Chet Ramey
> On 7/13/12 8:53 AM, Daniel Amthor wrote:
>
> Yeah, that's an assignment error. Posix says a non-interactive shell
> should exit in that case and that an interactive shell should write an
> error message without exiting. Bash doesn't ex
LDFLAGS) precisely because of flags like this. This is already how
Automake does things; the bug comes down to bash's build system not
following existing convention. It's not reasonable to have to duplicate
CFLAGS in LDFLAGS to avoid the reported link error.
--Daniel
--
NAME = Daniel
bject.
That said, I'm not sure why CFLAGS and CFLAGS_FOR_BUILD should be
different, given that this is a "simple" build where build = host =
target.
--Daniel
--
NAME = Daniel Richard G. _\|/_Remember, skunks
MAIL = sk...@iskunk.org (/o|o\) _- don't smell bad---
M
library or mismatched ABI for -ldl
Fatal error.
gmake[1]: *** [mkbuiltins] Error 1
gmake[1]: Leaving directory `/tmp/bash-4.2.build/builtins'
gmake: *** [builtins/builtext.h] Error 1
The attached patch (against the 4.2 source) fixes the problem for me.
--Daniel
--
NAME = D
that the man page section on "trap ERR" says that the trap is
triggered if a "simple command" returns >0 (sharing exceptions with "set
-e"). It seems however that the trigger is the same as for "set -e", as in
trap 'echo "error caught ($?), exiting"; exit 1' ERR
(exit 2)
echo done
Question 2: Are "set -e" and "trap ... ERR" triggered by the same events?
Clues would be appreciated.
--
Daniel Villeneuve
AD OPT, a Kronos Division
>From "man bash"
When used with [[, The < and > operators sort lexicographically
using the current locale.
You want (( and )):
$ if (( 1000 > 200 )); then echo pass; else echo wierd; fi
pass
Daniel.
On Fri, Nov 19, 2010 at 19:45, john.ruckstuhl wrote:
&
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
Am Dienstag, 23. Februar 2010 20:45:31 schrieb Greg Wooledge:
> On Tue, Feb 23, 2010 at 08:30:16PM +0100, Daniel Bunzendahl wrote:
> > if [ !$LSEITE ]; then
>
> You want: if [ ! "$LSEITE" ]
this dosn't work.
But I earsed the if-loop. And it works. (dont overwrite
--
and so on (500 lines... so I don't show it all)
In the last if-loop LSEITE will be set if LSEITE isn't set.
This is for no parameters on command-line.
But how I wrote: It ever works but now it lost the -l 104 ... the -f is no
Problem...
My question wasn't
1 - 100 of 113 matches
Mail list logo
