On Tue, Sep 1, 2015 at 4:24 PM, Andreas Schwab
wrote:
> Dennis Williamson writes:
>
> > $ echo $((foo)) # expansion succeeds, indirection fails
> > dash: 4: Illegal number: bar
>
> The indirection didn't fail, it just didn't produce a number, so the
>
On Wed, Sep 2, 2015 at 2:16 AM, Andreas Schwab
wrote:
> Dennis Williamson writes:
>
> > I disagree. The _expansion_ produced "bar"
>
> That's not an expansion. Only $ introduces an expansion.
>
> Andreas.
>
>
The $ is implied.
--
Visit serv
On Thu, Sep 3, 2015 at 8:45 AM, Stephane Chazelas <
stephane.chaze...@gmail.com> wrote:
> 2015-09-01 16:23:08 -0400, Greg Wooledge:
> > On Tue, Sep 01, 2015 at 03:13:57PM -0500, Dennis Williamson wrote:
> > > The version of dash I have handy (0.5.7) has math support wh
On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote:
> On 10/16/15 3:19 AM, 積丹尼 Dan Jacobson wrote:
> > Type ^Racb^C^R^R
> > (Search backwards for abc, then hit ^C, then try searching backwards
> > some more using the last search string.)
> >
> > My problem is why must bash zap the memory of abc ju
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
I considered help-bash for this, but I settled on bug-bash since it's about
an in-development version.
$ colors=(red green blue)
$ printf '%s\n' "${colors[*]@a}"
a a a
Which is consistent with the documentation:
a The expansion is a string consisting of flag values
representin
On Tue, Nov 3, 2015 at 10:29 AM, wrote:
> An example is better than thousand words:
>
> $ seq 1 2 9 > odd
> $ seq 2 2 10 > even
> $ paste -d "" odd even
> 12
> 34
> 56
> 78
> 910
> $ paste -d"" odd even
> 2
> 4
> 6
> 8
> 10
>
> Like you can see, with no space between the option (-d) and the null
On Nov 3, 2015 12:47 PM, "Julio C. Neves" wrote:
>
> Thanks Dennis,
> I know that you are rigth, but "paste -d"" odd even" and "paste -d "" odd
even" are not the same? The diference is only a space between the option
and its parameter.
It might be handy to have some of the escapes that work in $'string'
quoting to also work in prompts especially now with the ${parameter@P}
transformation.
Specifically the hex, unicode and control ones: \xHH, \u, \U
and \cx.
I presume that the dollar-single-quote escapes should not b
On Wed, Oct 28, 2015 at 8:55 AM, Chet Ramey wrote:
> On 10/27/15 5:02 PM, Greg Wooledge wrote:
> > I decided to play around with the ${var@P} expansion in 4.4-beta.
> >
> > imadev:~$ red=$(tput setaf 1) reset=$(tput sgr0)
> x='\[$red\]\u\[$reset\]@\h:\w\$ '; printf %s "${x@P}" | od -t x1
> >
On Thu, Nov 5, 2015 at 6:26 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:
> It might be handy to have some of the escapes that work in $'string'
> quoting to also work in prompts especially now with the ${parameter@P}
> transformation.
>
> Specifical
On Fri, Nov 6, 2015 at 7:51 AM, Chet Ramey wrote:
> On 11/5/15 7:45 PM, Dennis Williamson wrote:
>
> > That's what the \[ and \] escape sequences expand to and use to
> > communicate information to readline about invisible characters in the
> > promp
On Mon, Nov 9, 2015 at 5:09 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:
>
>
> On Thu, Nov 5, 2015 at 6:26 PM, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
>
>> It might be handy to have some of the escapes that work in $'stri
On Tue, Nov 10, 2015 at 12:14 PM, Andreas Schwab
wrote:
> Dennis Williamson writes:
>
> > But wait, you don't need the intermediate step! It already works!!!
> >
> > prompt=$'\u, something about dominoes \U1F061 \@ '
>
> You should quote the b
On Fri, Nov 13, 2015 at 10:13 AM, Griff Miller II
wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: cygwin
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unkno
On Tue, Nov 17, 2015 at 4:16 PM, Ángel González wrote:
> While we are talking about new prompt escapes, I would love to be able
> to put in the prompt escapes elapsed time values from the previous
> command, so prefixing with time(1) could be redundant (if the intended
> resource was provided as
On Mon, Jan 4, 2016 at 3:07 PM, Eduardo A. Bustamante López <
dual...@gmail.com> wrote:
> Take into account that many options have been provided (history -d, the
> space
> prefix, even editing .bash_history yourself).
>
> But you request a single key stroke to do this... why?
>
> If you enter a pa
On Mon, Jan 4, 2016 at 4:05 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:
>
>
> On Mon, Jan 4, 2016 at 3:07 PM, Eduardo A. Bustamante López <
> dual...@gmail.com> wrote:
>
>> Take into account that many options have been provided (history -d, the
On Mon, Jan 4, 2016 at 4:35 PM, Dennis Williamson <
dennistwilliam...@gmail.com> wrote:
>
>
> On Mon, Jan 4, 2016 at 4:05 PM, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 4, 2016 at 3:07 PM, Eduardo A. Bustamante Lóp
>
>
>
Either EXECIGNORE should block execution or type -a should indicate that
its argument matches a pattern in EXECIGNORE.
I vote for the latter so a user isn't surprised by execution without a
means to identify where it came from. I would also prefer another name. If
the purpose is to reduce co
$ type -a ls
ls is /bin/ls
$ # ls tab completion includes ls
$ ls foo
foo
$ EXECIGNORE=/bin/ls
$ type -a ls
bash: type: ls: not found
$ # ls tab completion does not include ls
$ ls foo
foo
$ /bin/ls foo
foo
So ls is still executed despite the setting. I tried the same with
/usr/bin/find and got th
On Jun 2, 2016 11:25 AM, "Charles T. Smith"
wrote:
>
> Hello,
>
> I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't
refresh
> my command line when scrolling through my history - the last tokens are
often
> not shown until I move the cursor there. Is that due to a change in bash?
On Aug 13, 2016 6:36 AM, "L. A. Walsh" wrote:
>
> I was looking at how the 'ldd' command(bash script) on my system and
> came across the code usage:
>
> for file do ## about line 138 in my version
> ...
> case $file in
> */* :
> ;;
> *) file=./$file
> ;;
> esac
> ...
> done
>
On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz
wrote:
> Has thought been given, over the years, to extending bash to do
> what make does, in the obvious way that I am about to describe?
>
> It would be a matter of having chosen build commands do nothing if their
> outputs are newer than their in
On Tue, Dec 6, 2016 at 4:09 PM, L A Walsh wrote:
>
> Is there a way, in bash, to filter stderr and let the
> filtered result continue on stderr with the original
> stdout being output on stdout?
>
> with prog being the program to filter, and RE_filt being the
> filtering expression, conceptually,
On Dec 30, 2016 11:20 PM, "Peter & Kelly Passchier" <
peterke...@passchier.net> wrote:
Thanks Dennis and Grisha! I understand.
I had thought that every line that is piped into bash is it's own shell
alignment, but I understand it's more like sourcing, so these wo
subshell line.
When the variable s is set to readonly the script does not exit and echoes
"abc":
#!/bin/bash
set -e
readonly s=$(false)
echo "abc"
This behavior is unexpected. I could reproduce the bug
on ubuntu 16.04 with bash version 4.3-14ubuntu1.1
Regards,
Dennis Kuhn
s
When set -e is in effect in a subshell, the exit status of commands,
functions, and sub-subshells is converted to 1.
$ ( ( exit 75 ) ); echo $?
75
$ (set -e; ( exit 75 ) ); exit $?
1
Versions of bash prior to 4.1 didn't convert all exit statuses to 1
when set -e was in effect.
$ uname -a
L
Quoting Chet Ramey :
I will change back to the pre-bash-4.1
behavior for the next version.
That's fantastic. Thank you!
There really isn't any requirement other than the
exit status be non-zero
Since I bothered to dig through the standard, I'll document what I
found here in case it's use
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
/+bug/516974
Is the 4.0 branch still supported and is this going to be patched? Or
should Ubuntu patch this as a vendor patch?
Just wondering.
Cheers,
Dennis
>
> --- bash-4.1/builtins/declare.def.~1~ 2009-11-26 01:42:00.0 +0100
> +++ bash-4.1/builtins/declare.def 20
MAILPATH CDPATH
+ eval test '${CDPATH+y}'
++ test
+ :
+ :
+ :
+ exec
+ :
+ :
+ PATH_SEPARATOR=:
+ as_myself=
+ case $0 in
+ as_myself=./configure
+ test x./configure = x
+ test '!' -f ./configure
malloc: ../bash-5.2.21/dispose_cmd.c:249: assertion botched
free: called with alrea
On 3/4/24 12:05, Chet Ramey wrote:
On 2/29/24 12:11 PM, Dennis Clarke via Bug reports for the GNU Bourne
Again SHell wrote:
Well this has me a bit baffled.
I downloaded the bash source tarball for 5.2.21 and then applied the
few patches to get me to :
io$
io$ which bash
/opt/bw/bin/bash
io
was happening over and over with different builds. Only on
that oddball hardware of course.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
'/opt/bw/build/bash-5.2.32_rhel9_amd64.001/examples/loadables'
make: [Makefile:846: install] Error 2 (ignored)
Not very helpful.
This is off the shelf bone stock RHEL9 with the default compiler and
linker and nothing remotely interesting.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
On 8/26/24 16:29, Chet Ramey wrote:
On 8/24/24 11:53 PM, Dennis Clarke via Bug reports for the GNU Bourne
Again SHell wrote:
This seemed to happen over and over and only during "make install".
There are a number of loadable builtins that require arrays and don't build
with
On 8/26/24 16:29, Chet Ramey wrote:
On 8/24/24 11:53 PM, Dennis Clarke via Bug reports for the GNU Bourne
Again SHell wrote:
This seemed to happen over and over and only during "make install".
There are a number of loadable builtins that require arrays and don't build
with
201 - 237 of 237 matches
Mail list logo
