On Sat, Feb 17, 2024, 20:54 Greg Wooledge wrote:
> On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> > After further examination, the examples with "fg $$" and "fg $!" clearly
> do not bring the subshell into the foreground, as they are evaluated prior
> to the subshells background ex
I was unaware of TMOUT. Now I have a backup as well. Thanks for tolerating my
inexperience.
On Sat, Feb 17, 2024 at 2:54 PM, Greg Wooledge wrote: On
Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> After further examination, the examples with "fg $$" and "fg $!" clearly do
> no
On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> After further examination, the examples with "fg $$" and "fg $!" clearly do
> not bring the subshell into the foreground, as they are evaluated prior to
> the subshells background execution.
> I'm trying to bring the subshell to the fo
After further examination, the examples with "fg $$" and "fg $!" clearly do not
bring the subshell into the foreground, as they are evaluated prior to the
subshells background execution.
I'm trying to bring the subshell to the foreground to perform an exit, after a
delay.
Ultimately, it will be
On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote:
> Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg
> %+; exit ) &
You're using %% or %+ inside a shell where there have NOT been any
background jobs created yet. The sleep 15s runs in the foreground,
because
Configuration Information [Automatically generated, do not change]:Machine:
x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2 -flto=auto
-ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong
-Wformat -Werror=format-security -Wall uname output: Linux
HP-ProBook-6450b-5
Hi Grisha,
I didn’t know to look there (I’m still pretty new to the Bash source).
Thanks, this is exciting!
Best,
Seth
On Jan 16, 2024, at 12:18 PM, Grisha Levit
wrote:
On Tue, Jan 16, 2024, 11:01 Seth Sabar <[1]sethsa...@gmail.com> wrote:
Are you planni
On Tue, Jan 16, 2024, 11:01 Seth Sabar wrote:
> Are you planning on releasing a patch for this? If you'd like me to try to
> prepare a patch, I'd appreciate some guidance around the various
> dequote_... functions in subst.c. Thanks!
>
Hi Seth,
Chet has committed a fix for this in the devel bran
Are you planning on releasing a patch for this? If you'd like me to try to
prepare a patch, I'd appreciate some guidance around the various
dequote_... functions in subst.c. Thanks!
Best,
Seth
On Wed, Dec 27, 2023 at 1:03 PM Chet Ramey wrote:
> On 12/25/23 5:00 PM, Seth Sabar wrote:
> > Hi all,
On 12/25/23 5:00 PM, Seth Sabar wrote:
Hi all,
I'm reaching out to report what I believe to be a bug with the
*--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the
utf-8 character */001* as an escape character. However, when using the
pretty-print feature in Bash, this doesn'
On Mon, Dec 25, 2023 at 05:00:37PM -0500, Seth Sabar wrote:
> I'm reaching out to report what I believe to be a bug with the
> *--pretty-print* feature in bash-5.2.
Tangentially, this option doesn't seem to be documented outside of "bash
--help":
$ git clone https://git.savannah.gnu.org/git/b
Hi all,
I'm reaching out to report what I believe to be a bug with the
*--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the
utf-8 character */001* as an escape character. However, when using the
pretty-print feature in Bash, this doesn't seem to be considered. So, for
example,
On Tue, Jun 27, 2023, 07:23 alex xmb ratchev wrote:
>
>
> On Tue, Jun 27, 2023, 04:55 Kaif Khan wrote:
>
>> Thank you for your response, but my bug is rather very simple and not
>> complicated. I am attaching a video to explain the bug.
>>
>
whats the output of
declare -p PS0 PS1 PROMPT_COMMAND
if u modify PS1 , u must enclose escape / color codes in literarly \[ and \]
eg
PS1=$'\[\e[0;1m\]bold\[\e[0m\] '
and the err u say , looks like u didnt make that proper bind cmd
On Mon, Jun 26, 2023, 19:15 Kaif Khan wrote:
>
>
dead.bashbug
Description: Binary data
On 7/27/22 2:59 AM, C. Cicada wrote:
> Version : 5.1.16
> OS: Fedora
> Problem: under Chinese (both simplified and tradition), bash buildin command
> 'type' has traslation mistake in its help file.
Hi. Thanks for the report. Please contact the GNU Translation project about
translation errors.
I
Version : 5.1.16
OS: Fedora
Problem: under Chinese (both simplified and tradition), bash buildin command
'type' has traslation mistake in its help file.
Under zh_TW.utf8, 'type --help' shows
type: type [-afptP] 名�Q [名�Q …]
�@示指令��型的�Y��。
��於每一�� <名�Q>，指示如果做�橹噶钏��⑷绾伪唤忉�。
�x��：
-a
On Thu, May 06, 2021 at 10:42:36AM +0300, Oğuz wrote:
> 6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> yazdı:
> >
> > But why is $# decremented after the first unset?
>
> Because `x[0]' existed then, and the number of x's members changed with its
> removal. `${
6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> yazdı:
>
> But why is $# decremented after the first unset?
>
Because `x[0]' existed then, and the number of x's members changed with its
removal. `${#x[@]}' doesn't give you the top index of `x', it expands to
the n
6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> yazdı:
> Hi!
>
> Considering the example given in https://unix.stackexchange.
> com/a/648243/320598 I think it may be a bug, or an inappropriately
> documented feature.
>
> Basically:
> % x=(1 2 3)
> % echo "${#x[@]}
Hi!
Considering the example given in https://unix.stackexchange.com/a/648243/320598
I think it may be a bug, or an inappropriately documented feature.
Basically:
% x=(1 2 3)
% echo "${#x[@]}"; echo "${x[@]}"
3
1 2 3
% unset x[0]
% echo "${#x[@]}"; echo "${x[@]}"
2
2 3
% unset x[0]
% echo "${#x[@
Jay via Bug reports for the GNU Bourne Again SHell
writes:
> I have no idea what the "ash" the bug report refers to
> is (there is an ancient shell of that name, but I cannot imagine any
> distribution including that, instead of one of its bug fixed and updated
> successors, like say, dash)
Well,
Thanks for your feedback.
For reference, other details are as follows:
In addition to bash, the distribution includes sh and ash
shells/scripts.
▶—— Linux Kernel ——◀
Kernel Release: 4.19.23
Build Date: Tue Feb 19 15:07:58 GMT 2019
Build GCC: 7.3.0
OS Support: GNU/Linux
On Wed, 17 Mar 2021 at 23:05, Greg Wooledge wrote:
> On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote:
> > | Operating system is BionicPup64 8.0.
> > That might. More importantly is probably whatever package management
> > system it uses. I have no idea what the "ash" the bug rep
On Wed, Mar 17, 2021 at 10:59:42AM +0700, Robert Elz wrote:
> | Operating system is BionicPup64 8.0.
>
> That might. More importantly is probably whatever package management
> system it uses. I have no idea what the "ash" the bug report refers to
> is (there is an ancient shell of that name,
Date:Tue, 16 Mar 2021 22:08:17 -0500
From:Dennis Williamson
Message-ID:
| In any case this points to larger chunks being more efficient.
This is not news, doing reads (or writes) using bigger buffers (more
bytes at a time) means less system calls, and compared to
Date:Tue, 16 Mar 2021 18:01:24 -0400
From:Jay via Bug reports for the GNU Bourne Again SHell
Message-ID: <86f1f224-2930-ee73-5431-6e130d92f...@aim.com>
First, thanks Lawrence for the translation from RTF, I am one of
the people he intended to help... The RTF form I
.
On Tue, Mar 16, 2021, 10:22 PM Lawrence Velázquez wrote:
> > On Mar 16, 2021, at 11:08 PM, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
> >
> > I've been playing with your optimized code changing the read to grab data
> > in chunks like some of the other optimized code does - thus
> On Mar 16, 2021, at 11:08 PM, Dennis Williamson
> wrote:
>
> I've been playing with your optimized code changing the read to grab data
> in chunks like some of the other optimized code does - thus extending your
> move from by-word to by-line reading to reading a specified larger number
> of c
On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez wrote:
> > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne
> Again SHell wrote:
> >
> > Hello,
> >
> > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
> > systems more than once either through their
> On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne Again
> SHell wrote:
>
> Hello,
>
> I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
> systems more than once either through their instability with libraries
> or just excess stress.
>
> I don'
Hello,
I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
systems more than once either through their instability with libraries
or just excess stress.
I don't consider current case to be either of the above; see attached.
The system is modern Intel computer,
On 2/1/21 5:29 PM, George R Goffe wrote:
Hi,
I just checked out the "latest" bash from the repo at savanna.gnu.org and am
having build problems.
I have tried --with-gnu-malloc and it's alias and also tried building without
any malloc parameters in configure without success. Enclosed below is
Hi,
I just checked out the "latest" bash from the repo at savanna.gnu.org and am
having build problems.
I have tried --with-gnu-malloc and it's alias and also tried building without
any malloc parameters in configure without success. Enclosed below is what I'm
seeing. I have a full build log a
On 10/11/19 12:07 AM, George R Goffe via Bug reports for the GNU Bourne
Again SHell wrote:
> Hi,
>
> I've been seeing these crashes randomly for the past month. This happens when
> I try to use filename completion. Is this a bash bug?
It's hard to say, since the crash is a
Hi,
I've been seeing these crashes randomly for the past month. This happens when I
try to use filename completion. Is this a bash bug?
Regards,
George...
This is the bash version: bash-5.0.7-3.fc31.x86_64
xpdAssertion 'pthread_mutex_init(&b->memfd_cache_mutex, NULL) ==
On Wed, Jul 10, 2019 at 09:15:14AM -0400, Chet Ramey wrote:
> On 7/10/19 4:01 AM, westlake wrote:
> > If a normal user types "su -l" and issues this "ls" statement,
> This account has the `extglob' shell option enabled.
"su -l" gives you a login shell, so this instance of bash is reading
/etc/prof
On 7/10/19 4:01 AM, westlake wrote:
> System: linux 64-bit (debian stable, latest release buster)
> Bash version: GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
>
> This bug occurs with the root account,
>
> If a normal user types "su -l" and issues this "ls" statement,
>
> ls -ld .!(?
System: linux 64-bit (debian stable, latest release buster)
Bash version: GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
This bug occurs with the root account,
If a normal user types "su -l" and issues this "ls" statement,
ls -ld .!(?(.))
the output is without error. (the output list
On Tue, May 28, 2019 at 04:43:42PM +0200, Andreas Kusalananda Kähäri wrote:
> On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAG
On 5/28/19 7:56 AM, r...@minigeek.srve.com wrote:
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release
>
> Description:
> I deleted the file .DS_Store fom a fat32 partition as root. bash
> properly warned me and I answered y which deleted that file.
> A second different fi
On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote:
> 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_MACHTY
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
On Sat, 18 Nov 2017, PePa wrote:
On 11/15/2017 11:06 PM, Greg Wooledge wrote:
On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote:
tab=$'\t'
echo "$tab " | xod
Where can I get xod?
I don't know about xod, but od is a standard utility, and hd is also
commonly installed.
--
Chris
On 11/15/2017 11:06 PM, Greg Wooledge wrote:
On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote:
tab=$'\t'
echo "$tab " | xod
Where can I get xod? I tried looking here https://github.com/xodio/xod
and I found a perl script that couldn't be piped into.
Peter
On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote:
> $ echo "$'\t' " | xod
>
> Dump: standard input
>
> Offset:0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
>
> : 24 27 5c 74 27 20 0a
To put Chet's reply a different way, don't think of $'...' as a dollar
expansion ( like ${} $() or $(()) ) it isn't, it is just another form of
quoting (very similar to '' quoting) and is processed in the same way,
at the same places, as '' quoting would be.
In "'xxx'" the single quotes are just c
On 11/15/17 10:01 AM, Rick Richardson wrote:
> $ echo "$'\t' " | xod
>
> Dump: standard input
>
> Offset:0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
>
> : 24 27 5c 74 27 20 0a | $'\t&#x
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
: 24 27 5c 74 27 20 0a | $'\t' . |
A Bash bug???
$ echo $'\t'' ' | xod
Dump: standard input
Offset:0 1 2 3 4 5 6 7 8
On 4/23/17 2:52 AM, Noneofthebusiness Ofsomehere wrote:
> There is an annoying problem I struggle with that might be associated with
> tab completion. I would like to share it with you. It might be a bug. I
> really don't know and I'm new to Linux and programming, hence I am being
> extra careful i
There is an annoying problem I struggle with that might be associated with tab
completion. I would like to share it with you. It might be a bug. I really
don't know and I'm new to Linux and programming, hence I am being extra careful
in naming this a bug:
https://unix.stackexchange.com/questio
You can do:
local var; var=$(...); ... $?
No need to make the declaration and assignment at the same time.
On Tue, Aug 23, 2016 at 2:34 AM, Weshakie Löwe wrote:
> When storing the value of code executed in a subshell the return value is
> always 0 if the variable is local.
>
> Code example:
>
> A(){
> local return_value="$(bash -c "exit 1")"
> echo $?
> }
>
> function A: returns 0 - even though obvi
When storing the value of code executed in a subshell the return value
is always 0 if the variable is local.
Code example:
A(){
local return_value="$(bash -c "exit 1")"
echo $?
}
function A: returns 0 - even though obviously the return value is 1.
B(){
return_value="$(bash -c "exit 1")"
e
> Am 22.06.2016 um 11:34 schrieb John Lawlor :
>
> Hi,
>
> I came across some unusual behaviour in bash using the ‘-c’ parameter.
>
> If I do the following:
>
> bash -c "ping 127.0.0.1 > $HOME/console.log" &
>
> This starts two processes bash and ping:
>
> john 18038 17951 0 09:26
On Wed, Jun 22, 2016 at 10:34:59AM +0100, John Lawlor wrote:
> If I do the following:
>
> bash -c "ping 127.0.0.1 > $HOME/console.log" &
> Now if I kill bash:
>
> Bash is killed but not the child ping process. I was expecting that to be
> killed also.
Not a bug. If you want a signal (e.g. SI
Hi,
I came across some unusual behaviour in bash using the '-c' parameter.
If I do the following:
bash -c "ping 127.0.0.1 > $HOME/console.log" &
This starts two processes bash and ping:
john 18038 17951 0 09:26 pts/14 00:00:00 bash -c ping 127.0.0.1 >
/home/john/console.log
john 1
Got it, thanks
On Wed, Jun 22, 2016 at 12:21 PM, Chet Ramey wrote:
> On 6/21/16 9:35 PM, Roel Van de Paar wrote:
>
> > Bash Version: 4.2
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> > DONE=0 at the end of the 'Repeat-By' script - should be 1 ?
> >
> > Repeat-By:
On 6/21/16 9:35 PM, Roel Van de Paar wrote:
> Bash Version: 4.2
> Patch Level: 46
> Release Status: release
>
> Description:
> DONE=0 at the end of the 'Repeat-By' script - should be 1 ?
>
> Repeat-By:
> LINE='test'; DONE=0; echo ${LINE} | if grep -q 'test'; then DONE=1;
> echo "
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -
On 12/21/14 3:28 PM, Richard W. Marsden wrote:
> steps to produce
>
> hide cursor
> setterm -cursor off
>
> call the bash built-in read command as follows: silent, wait 1 second, read
> 1 character to variable KEY
> read -s -t 1 -n 1 KEY
>
> while the read command is in a loop, control +
Hey,
without checking the source: reset utility from ncurses fixes your term.
this one is reproducible.
cheers,
pg
On Sun, Dec 21, 2014 at 9:28 PM, Richard W. Marsden wrote:
> steps to produce
>
> hide cursor
> setterm -cursor off
>
> call the bash built-in read command as follows: sil
steps to produce
hide cursor
setterm -cursor off
call the bash built-in read command as follows: silent, wait 1 second, read
1 character to variable KEY
read -s -t 1 -n 1 KEY
while the read command is in a loop, control + c is trapped successfully
and the cursor is un-hidden
setterm
On 12/15/14 11:13 AM, Dan Douglas wrote:
> Ah ok I thought -e basically negated the effect of -r for some reason but I
> guess not (like you can still use \ to escape line continuations without -r it
> seems).
They're separate but kind of clumsy to use together for line continuations.
`read' end
On Monday, December 15, 2014 10:47:29 AM Chet Ramey wrote:
> On 12/15/14, 7:11 AM, Dan Douglas wrote:
>
> > I'm generally interested in what read with (or without) -r combined with -e
> > even means.
>
> I'm not sure what you're driving at. The -e option says how to read the
> line; the -r option
On 12/15/14, 7:11 AM, Dan Douglas wrote:
> I'm generally interested in what read with (or without) -r combined with -e
> even means.
I'm not sure what you're driving at. The -e option says how to read the
line; the -r option affects how the characters are processed after being
read.
--
``The
On 12/15/14, 7:11 AM, Dan Douglas wrote:
> I understand that read's now basically useless behavior without -r
> was originally there to make using it interactively without a line editor
> slightly easier.
Ask David Korn, since he originally added options to the read builtin.
None of the `pure'
On Sunday, December 14, 2014 04:27:51 PM Chet Ramey wrote:
> On 12/13/14 12:06 AM, Daniel A. Gauthier wrote:
> >
> > If you do a "read -e -r var" in bash, and use tab completion to fill-in
> > a filename, it fills in "My\ File\ Name.txt" and that's exactly
> > what's read into the variable. The f
On 12/13/14 12:06 AM, Daniel A. Gauthier wrote:
>
> If you do a "read -e -r var" in bash, and use tab completion to fill-in
> a filename, it fills in "My\ File\ Name.txt" and that's exactly
> what's read into the variable. The fix is simple, in tab completion,
> the text placed into the buffer sh
If you do a "read -e -r var" in bash, and use tab completion to fill-in
a filename, it fills in "My\ File\ Name.txt" and that's exactly
what's read into the variable. The fix is simple, in tab completion,
the text placed into the buffer should be in the same format that the
read is expecting, so
On 2013-08-09 16:10, Chet Ramey wrote:
> So is there enough of a need to make 0 do something different? Or does
> $BASH_COMMAND suffice? (I suspect the answer to that question is "no",
> because it deals with commands rather than input lines.)
I agree, for this case I don't think $BASH_COMMAND su
On 7/19/13 11:23 AM, Mike Fied wrote:
> Dear GNU developer/code maintainer,
>
> Please take a second to take a look at this problem - this might or might
> not be a bug, or rather a feature is not implemented in BASH:
> I am trying to get the current or "last" command line printed as the result
>
Dear GNU developer/code maintainer,
Please take a second to take a look at this problem - this might or might
not be a bug, or rather a feature is not implemented in BASH:
I am trying to get the current or "last" command line printed as the result
of history, or a BASH variable ( to my knowledge i
Am 07.05.2012 22:46, schrieb Chet Ramey:
> On 5/3/12 5:53 AM, Ruediger Kuhlmann wrote:
>> Hi,
>>
>> please try the following bash script:
>>
>> a=x
>> del="$(echo -e "\\x7f")"
>>
>> echo "$del${a#x}" | od -ta
>> echo "$del ${a#x}" | od -ta
>> echo " $del${a#x}" | od -ta
>>
>> Using bash 3.2, the ou
On 5/3/12 5:53 AM, Ruediger Kuhlmann wrote:
> Hi,
>
> please try the following bash script:
>
> a=x
> del="$(echo -e "\\x7f")"
>
> echo "$del${a#x}" | od -ta
> echo "$del ${a#x}" | od -ta
> echo " $del${a#x}" | od -ta
>
> Using bash 3.2, the output is:
>
> 000 del nl
> 002
> 000 d
Maarten Billemont wrote:
This mail has gone slightly off-topic. Hit mark as read if you don't
care for that sort of thing.
I don't care if you like evil in your sexual play or in your vendettas.
When you write code, evil is nothing worth liking. In programming,
evil is defined as so
This mail has gone slightly off-topic. Hit mark as read if you don't care for
that sort of thing.
On 27 Apr 2012, at 21:02, Linda Walsh wrote:
> Greg Wooledge wrote:
>
>> NEVER use eval plus a brace expansion to generate a list. That's just
>> freakin' evil. And unsafe:
>
> But I _like_ evi
Am 03.05.2012 19:41, schrieb John Kearney:
> Am 03.05.2012 15:01, schrieb Greg Wooledge:
>>> Yours, Rüdiger.
>>> a=x
>>> del="$(echo -e "\\x7f")"
>>>
>>> echo "$del${a#x}" | od -ta
>>> echo "$del ${a#x}" | od -ta
>>> echo " $del${a#x}" | od -ta
>> Yup, confirmed that it breaks here, and only when t
Am 03.05.2012 15:01, schrieb Greg Wooledge:
>> Yours, Rüdiger.
>> a=x
>> del="$(echo -e "\\x7f")"
>>
>> echo "$del${a#x}" | od -ta
>> echo "$del ${a#x}" | od -ta
>> echo " $del${a#x}" | od -ta
> Yup, confirmed that it breaks here, and only when the # parameter expansion
> is included.
>
> imadev:~$
> Yours, Rüdiger.
> a=x
> del="$(echo -e "\\x7f")"
>
> echo "$del${a#x}" | od -ta
> echo "$del ${a#x}" | od -ta
> echo " $del${a#x}" | od -ta
Yup, confirmed that it breaks here, and only when the # parameter expansion
is included.
imadev:~$ del=$'\x7f' a=x b=
imadev:~$ echo " $del$b" | od -ta
0
--- Begin Message ---
Hi,
please try the following bash script:
a=x
del="$(echo -e "\\x7f")"
echo "$del${a#x}" | od -ta
echo "$del ${a#x}" | od -ta
echo " $del${a#x}" | od -ta
Using bash 3.2, the output is:
000 del nl
002
000 del sp nl
003
000 sp del nl
003
howeve
Mike Frysinger wrote:
Anything else you wanna tell me NEVER/ALWAYS to do?
try ALWAYS being polite. but i guess that'll NEVER happen.
oh well, thankfully kmail can auto-mute based on sender.
-mike
«"Always" "good to prejudge" "everything someone says" based on how
they interact w
Greg Wooledge wrote:
NEVER use eval plus a brace expansion to generate a list. That's just
freakin' evil. And unsafe:
===
But I _like_ evil sometimes! >:->
imadev:~$ a=(lib tmp bin share '`date`')
imadev:~$ (export IFS=,;eval "echo /usr/{${a[*]}}")
/usr/lib /usr/tmp /usr/bin /usr/shar
On Thu, Apr 26, 2012 at 08:47:39PM -0700, Linda Walsh wrote:
> Obviously, they were not complete beginners to bash -- to be
> reading
> arrays in from vars holding multi-line text? I would assume they'd have
> the
> intelligence to know when to use * or @ and I wouldn't have to talk down to
>
On Thursday 26 April 2012 23:47:39 Linda Walsh wrote:
> Anything else you wanna tell me NEVER/ALWAYS to do?
try ALWAYS being polite. but i guess that'll NEVER happen.
oh well, thankfully kmail can auto-mute based on sender.
-mike
signature.asc
Description: This is a digitally signed message pa
Maarten Billemont wrote:
On 26 Apr 2012, at 01:18, Linda Walsh wrote:
Ishtar:> echo "${b[*]}"
Please note that expanding array elements using [*] is usually NOT what anyone
wants.
---
It was exactly what I wanted for my example to work. Please don't suggest
non-working solutions to th
On Thu, Apr 26, 2012 at 2:16 PM, Greg Wooledge wrote:
> If the goal is to see the contents of an array, I'd use one of these,
> depending on how much detail I need:
>
> printf '<%s> ' "${array[@]}"; echo
>
> declare -p array
>
Or i'd use the args function Greg has shown before:
args() { printf
On Thu, Apr 26, 2012 at 05:54:27PM +0200, Maarten Billemont wrote:
> On 26 Apr 2012, at 01:18, Linda Walsh wrote:
> >
> > Ishtar:> echo "${b[*]}"
>
> You should always recommend the "${b[@]}" variant. "${b[*]}" is rarely
> useful in the event that your intent is to merge the array into a single
On 26 Apr 2012, at 01:18, Linda Walsh wrote:
>
> Ishtar:> echo "${b[*]}"
Please note that expanding array elements using [*] is usually NOT what anyone
wants. Be careful about recommending it to anyone.
"${b[*]}" # This throws away any usefulness of the array by merging all the
array elements
Ted Okuzumi wrote:
I am writing this e-mai to report to report a bug in bash
Description:
Cannot redirect into an array from multiline variable
Does not work:
echo "$mydata" | while read line; do myarray+=( "$line" ); done
Have you tried this?
Ishtar:> a='this
is
a
tes
Thank you for that detailed information. I really appreciate the 2
workarounds you provided.
I can confirm by adding in this line to my script:
shopt -s lastpipe
fixes the problem, confirming that it was indeed a subshell issue.
Best regards,
Ted
On Wed, Apr 25, 2012 at 10:50 AM, DJ Mills wr
On Wed, Apr 25, 2012 at 04:05:15PM -0400, Chet Ramey wrote:
> OK. Now make the call move_to_high_fd(0, 1, -1) and see if that fixes it.
cyclops:/var/tmp/bash/bash-4.2$ ./bash ~/foo
cyclops:/var/tmp/bash/bash-4.2$ ./bash -c 'shopt -s lastpipe; echo hi | read
f
On 4/25/12 3:09 PM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 02:54:07PM -0400, Chet Ramey wrote:
>> On 4/25/12 2:04 PM, Greg Wooledge wrote:
>>
>>> Maybe it only works on boxes with a very large "open files" resource
>>> limit. Perhaps the hard-coded 255 should be replaced with something
>>>
On Wed, Apr 25, 2012 at 02:54:07PM -0400, Chet Ramey wrote:
> On 4/25/12 2:04 PM, Greg Wooledge wrote:
>
> > Maybe it only works on boxes with a very large "open files" resource
> > limit. Perhaps the hard-coded 255 should be replaced with something
> > involving getrlimit() or similar?
>
> I se
On 4/25/12 2:04 PM, Greg Wooledge wrote:
> Maybe it only works on boxes with a very large "open files" resource
> limit. Perhaps the hard-coded 255 should be replaced with something
> involving getrlimit() or similar?
I see two potential fixes here. First, try changing the 255 to -1 and
see wha
On Wed, Apr 25, 2012 at 01:31:11PM -0400, Chet Ramey wrote:
> OK. Maybe someone with OpenBSD can debug the appropriate code in
> execute_cmd.c:execute_pipeline. Maybe the call to move_to_high_fd
> fails.
Breakpoint 1 at 0x41d5fc: file execute_cmd.c, line 2107.
Breakpoint 2 at 0x414aa3: file gene
On Wed, Apr 25, 2012 at 1:36 PM, Ted Okuzumi wrote:
> Please note that if I use a different command in the while loop it works.
>
> So instead of
> echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
>
> if I say:
> echo "$mydata" | while read -r line; do echo "$line" ; done
>
> The
On Wed, Apr 25, 2012 at 10:36:53AM -0700, Ted Okuzumi wrote:
> Please note that if I use a different command in the while loop it works.
>
> So instead of
> echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
>
> if I say:
> echo "$mydata" | while read -r line; do echo "$line" ; do
Please note that if I use a different command in the while loop it works.
So instead of
echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
if I say:
echo "$mydata" | while read -r line; do echo "$line" ; done
Then it works. To pipe output into a while statement works, normally,
On 4/25/12 1:10 PM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 12:55:06PM -0400, Greg Wooledge wrote:
>> It also fails on OpenBSD 5.0 using bash 4.2.10 from ports.
>
> And it also fails on OpenBSD 5.0 using bash 4.2.24 straight from the
> original sources.
OK. Maybe someone with OpenBSD can
1 - 100 of 170 matches
Mail list logo
