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
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: i686-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/loc
t all.
Any ideas for what might be causing this? Any obvious shell options or
suchlike that I should check?
Cheers,
John
On 3 Oct 2009 at 20:19, Wanna-Be Sys Admin wrote:
> John wrote:
>> If I do "history -w" then it writes the current history to
>> ~/.bash_history as expected.
>>
>> But if I do "history -a" then ~/.bash_history doesn't get changed, and
>>
Hi!
I believe the Bash Reference Manual is missing a key note for using "set
-o".
On the man page for "bash"
(https://tiswww.case.edu/php/chet/bash/bash.html), the following line is
present
* If *-o* is supplied with no /option-name/, the values of the current
options are printed. If *
I can see a couple reasons why it would be a good thing, and in the con
column only "I personally don't have time to go through the manual and make
these changes". but I'd happily upvote a patch from somebody that does.
On Sat, Jun 5, 2021, 09:24 Vipul Kumar
wrote:
> Hi,
>
> Isn't it a good ide
Léa, I see that in the section Ilkka quoted you were using it in the
plural. However Ilkka is exactly right; despite "they" being technically
plural, using it for somebody of undetermined gender has been in the
mainstream since long before inclusive language. "Someone left *their*
book, there's no
interfacing with an external tool absolutely seems like the correct answer
to me. a fact worth mentioning to back that up is that `jq` exists. billed
as a sed/awk for json, it fills all the functions you'd expect such an
external tool to have and many many more. interfacing from curl to jq to
bash
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
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
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 "
if you wanted this for your script - read all then start semantics, as
opposed to read-as-you-execute - would it work to rewrite yourself inside a
function?
function main() { ... } ; main
On Sun, Apr 7, 2024, 22:58 Robert Elz wrote:
> Date:Mon, 8 Apr 2024 02:50:29 +0100
> From:
I find that I cannot execute world-executable scripts when they are in
a directory which is mounted on a drive on an HBA (host bus adapter
card) in pass-thru mode, but the exact same scripts are executable
when they are in a directory on my boot drive (connected to
motherboard SATA).
Is this a bas
On Sat, Jun 18, 2011 at 1:51 PM, Jan Schampera wrote:
> Can you show the mount options of the filesystem?
Good call, I should have though of that. I had all the filesystems on
the non-boot drives mounted with the "user" option, which I just
learned from the mount man page also activate "noexec".
or example, this code prints the script location of every fork().
-
// bash-syspose.c - interpose so that bash shell prints $PS4 upon syscall
// Copyright 2011 John Reiser, BitWagon Software LLC. All rights reserved.
// Licensed under GNU General Public License, version 3 (GPLv3).
//
// Requir
Peng Yu wrote:
> I know that I should use =~ to match regex (bash version 4).
>
> However, the man page is not very clear. I don't find how to match
> (matching any single character). For example, the following regex
> doesn't match txt. Does anybody know how to match any character
> (should b
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
olution.
I mean you could do something like
#define MAX_SINGLE_BYTE_UTF8 0x7F
if (uvalue <= MAX_SINGLE_BYTE_UTF8)
I'm guessing the code was done originally for UTF-2 encoding.
what I suggest will fix the UTF-8 case and not affect the UTF-2 case.
On 02/18/2012 11:11 AM, Andreas Schwab wro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/2012 11:29 AM, Andreas Schwab wrote:
> John Kearney writes:
>
>> what I suggest will fix the UTF-8 case
>
> No, it won't.
>
>> and not affect the UTF-2 case.
>
> That is impossible.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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_VE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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_VE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can somebody explain to me what u32tochar is trying to do?
It seems like dangerous code?
from the context i'm guessing it trying to make a hail mary pass at
converting utf-32 to mb (not utf-8 mb)
int
u32tochar (x, s)
unsigned long c;
char
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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_VE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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_VE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2012 01:34 PM, Eric Blake wrote:
> On 02/20/2012 07:42 PM, Chet Ramey wrote:
>> On 2/18/12 5:39 AM, John Kearney wrote:
>>
>>> Bash Version: 4.2 Patch Level: 10 Release Status: release
>>>
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Initial code for testing \u functionality.
basically uses arrays that look like this
jp_JP_SHIFT_JIS=(
#Unicode="expected bmstring"
[0x0001]=$'\x01' # START OF HEADING
[0x0002]=$'\x02' # START OF TEXT
...
)
TestCodePage ja_JP.SHIFT_JIS jp_JP_S
Here is a diff of all the changed to the unicode
This seems to work ok for me. but still needs further testing.
My major goal was to make the code easier to follow and clearer.
but also generally fixed and improved it.
Added warning message
./bash -c 'printf "string 1\\U8fffStromg 2"'
./b
On 02/22/2012 01:52 AM, Chet Ramey wrote:
> On 2/21/12 3:51 AM, John Kearney wrote:
>
>> Bash Version: 4.2 Patch Level: 10 Release Status: release
>>
>> Description: Basically if setting the locale fails variable
>> should not be changed.
>
> I disagree. Th
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
printf "%q" "~" not escaped?
which means that this
eval echo $(printf "%q" "~")
results in your home path not a ~
unlike
eval echo $(printf "%q" "*")
as far as I can see its the only character that isn't treated as I
expected
On 02/22/2012 01:59 PM, Eric Blake wrote:
> On 02/22/2012 05:19 AM, Linda Walsh wrote:
>>
>>
>> Eric Blake wrote:
>>
>>
>>> Not only can wchar_t can be either signed or unsigned, you also have to
>>> worry about platforms where it is only 16 bits, such as cygwin; on the
>>> other hand, wint_t is al
^ caviot you can represent the full 0x10 in UTF-16, you just need 2
UTF-16 characters. check out the latest version of unicode.c for an
example how.
On 02/22/2012 11:32 PM, Eric Blake wrote:
> On 02/22/2012 03:01 PM, Linda Walsh wrote:
>> My question had to do with an unqualified wint_t no
nsion: Ubuntu Font should support pIqaD (Klingon)
https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/650729
On 02/23/2012 04:54 AM, Eric Blake wrote:
> On 02/22/2012 07:43 PM, John Kearney wrote:
>> ^ caviot you can represent the full 0x10 in UTF-16, you just
&g
On 02/25/2012 09:42 PM, Davide Baldini wrote:
> Configuration Information [Automatically generated, do not
> change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation
> CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VEN
I updated that wiki page
Hopefully its clearer now.
http://mywiki.wooledge.org/glob#extglob
On 02/26/2012 12:06 PM, Dan Douglas wrote:
> On Saturday, February 25, 2012 09:42:29 PM Davide Baldini wrote:
>
>> Description: A 'test.sh` script file composed exclusively of the
>> following text fails
On 02/22/2012 08:59 PM, Eric Blake wrote:
> On 02/22/2012 12:55 PM, Chet Ramey wrote:
>> On 2/21/12 5:07 PM, John Kearney wrote:
>>>
>>> Initial code for testing \u functionality.
>>
>> Thanks; this is really good work. In the limited testing I've
Actually this is something that still really confuses me as well.
In the end I gave up and just did this.
local LName="'\\''"
echo -n "'${1//"'"/${LName}}' "
I still don't really understand why this wont work
echo -n "'${1//"'"/"'\''"}' "
fds'\''dsfsdf'
On 02/28/2012 05:01 PM, Greg Wooledge wrote:
> On Tue, Feb 28, 2012 at 04:52:48PM +0100, John Kearney wrote:
>> The standard work around you see is
>> echo -n \'${1//\'/\'\\\'\'}\'" "
>&g
On 02/28/2012 05:22 PM, Roman Rakus wrote:
> On 02/28/2012 05:10 PM, John Kearney wrote:
>> wrap it with single quotes and globally replace all single quotes
>> in the string with '\''
> single quote and slash have special meaning so they have to be
> escaped,
On 02/28/2012 06:05 PM, Steven W. Orr wrote:
> On 2/28/2012 11:54 AM, John Kearney wrote:
>> On 02/28/2012 05:22 PM, Roman Rakus wrote:
>>> On 02/28/2012 05:10 PM, John Kearney wrote:
>>>> wrap it with single quotes and globally replace all single
>>>>
On 02/28/2012 06:16 PM, Eric Blake wrote:
> On 02/28/2012 09:54 AM, John Kearney wrote:
>> On 02/28/2012 05:22 PM, Roman Rakus wrote:
>>> On 02/28/2012 05:10 PM, John Kearney wrote:
>>>> wrap it with single quotes and globally replace all single
>>>> quote
On 02/28/2012 06:31 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
>> On 02/28/2012 05:49 PM, Greg Wooledge wrote:
>>> On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
And that means, there isn't way to substitute "something" to
' (single
On 02/28/2012 06:43 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
>>> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
>>>> On 02/28/2012 05:49 PM, Greg Wooledge wrote:
On 02/28/2012 06:52 PM, John Kearney wrote:
> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
>>>> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote
On 02/28/2012 07:00 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 06:52:13 PM John Kearney wrote:
>> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>>>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
On 02/28/2012 10:05 PM, Chet Ramey wrote:
> On 2/28/12 12:26 PM, John Kearney wrote:
>
>> But that isn't how it behaves.
>> "${test//str/""}"
>>
>> because str is replaced with '""' as such it is treating th
On 02/28/2012 11:07 PM, Chet Ramey wrote:
> On 2/28/12 4:28 PM, John Kearney wrote:
>>
>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>> On 2/28/12 12:26 PM, John Kearney wrote:
>>>
>>>> But that isn't how it behaves. "${test//str/"
On 02/28/2012 11:15 PM, Chet Ramey wrote:
> On 2/28/12 5:07 PM, Chet Ramey wrote:
>
>>> yhea but I think the point is that the current behavior is useless.
>>> there is no case where I want a " to be printed and start a double
>>> quoted string? and thats the current behavior.
>>>
>>>
>>> Not so i
On 02/28/2012 11:23 PM, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 PM, Chet Ramey wrote:
>>> On 2/28/12 4:28 PM, John Kearney wrote:
>>>>
>>>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>>>> On 2/
On 02/28/2012 11:44 PM, Chet Ramey wrote:
> echo "$(echo '$bar')"
actually these both output the same in bash
echo "$(echo '$bar')"
echo $(echo '$bar')
On 02/28/2012 11:23 PM, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 PM, Chet Ramey wrote:
>>> On 2/28/12 4:28 PM, John Kearney wrote:
>>>>
>>>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>>>> On 2/
d of file
echo ${a:-$(echo $'\'')}
'
echo "${a:-$(echo \')}"
'
This can not be logical behavior.
On 02/29/2012 11:26 PM, Chet Ramey wrote:
> On 2/28/12 10:52 AM, John Kearney wrote:
>> Actually this is something that still really confuses m
On 02/29/2012 11:53 PM, Linda Walsh wrote:
>
>
> Eric Blake wrote:
>
>> On 02/29/2012 12:26 PM, Linda Walsh wrote:
>>
Any pathname that contains a / should not be subject to PATH
searching.
>>
>> Agreed - as this behavior is _mandated_ by POSIX, for both sh(1)
>> and for execlp(2) an
On 03/01/2012 12:12 AM, Andreas Schwab wrote:
> John Kearney writes:
>
>> It isn't just the quote removal that is confusing.
>>
>> The escape character is also not removed and has its special
>> meaning.
>
> The esacape character is also a quote charac
On 02/29/2012 11:55 PM, Chet Ramey wrote:
> On 2/28/12 4:28 PM, John Kearney wrote:
>>
>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>> On 2/28/12 12:26 PM, John Kearney wrote:
>>>
>>>> But that isn't how it behaves.
>>>> "${te
.
Anybody interested in this sort of thing?
On 03/01/2012 11:48 PM, Linda Walsh wrote:
> John Kearney wrote: ... [large repetitive included text elided...]
>
>> why not just do something like this?
>>
> <26 line suggested 'header' elided...>
>
tagging it and navigating so, its what I do.
On 03/02/2012 03:54 AM, Clark J. Wang wrote:
> On Fri, Mar 2, 2012 at 08:20, John Kearney
> wrote:
>
>> :) :)) Personal best wrote about 1 lines of code which
>> finally became about 200ish to implement a readkey funct
On 03/03/2012 09:43 AM, Stefano Lattarini wrote:
> On 03/03/2012 08:28 AM, Pierre Gaston wrote:
>> On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini wrote:
>>
>>> Or here is a what it sounds as a marginally better idea to me: Bash could
>>> start supporting a new environment variable like "BASHLIB"
mean it shouldn't pretend
it knows what its doing when it doesn't, it should admit the problem so
that the problem can be fixed.
On 02/21/2012 04:28 AM, Chet Ramey wrote:
> On 2/19/12 5:07 PM, John Kearney wrote:
>> Can somebody explain to me what u32tochar is trying to
s a U+80 and turns it into a U+c3 and a U+80.
The way i rewrote the icconv code made it cleaner, safer and quicker,
please consider using it. I avoided the need for the strcpy among
other things.
On 02/21/2012 03:42 AM, Chet Ramey wrote:
> On 2/18/12 5:39 AM, John Kearney wrote:
>
Am 26.04.2012 06:26, schrieb Linda Walsh:
I know I can get
a="abcdef" echo "${a[2:4]}" = cde
how do I do:
typeset -a a=(apple berry cherry date); then get:
echo ${a[1:2]} = "berry" "cherry" ( non-grouped args)
I tried to do it in a function and hurt myself.
echo ${a[@]:1:2}
Am 28.04.2012 05:05, schrieb Linda Walsh:
Maarten Billemont wrote:
On 26 Apr 2012, at 06:30, John Kearney wrote:
Am 26.04.2012 06:26, schrieb Linda Walsh:
I know I can get
a="abcdef" echo "${a[2:4]}" = cde
how do I do:
typeset -a a=(apple berry cherry date); the
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:~$
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}&qu
I tend to do something more like this
function runJobParrell {
local mjobCnt=${1} && shift
jcnt=0
function WrapJob {
"${@}"
kill -s USR2 $$
}
function JobFinised {
jcnt=$((${jcnt}-1))
}
trap JobFinised
Am 03.05.2012 22:30, schrieb Greg Wooledge:
> On Thu, May 03, 2012 at 10:12:17PM +0200, John Kearney wrote:
>> function runJobParrell {
>> local mjobCnt=${1} && shift
>> jcnt=0
>> function WrapJob {
>>
RN[@]}" &
else
continue
fi
shift
done
sleep 1
done
}
Am 03.05.2012 23:23, schrieb John Kearney:
> Am 03.05.2012 22:30, schrieb Greg Wooledge:
>> On Thu, May 03, 2012 at 10:12:17PM +0
Am 04.05.2012 20:53, schrieb Mike Frysinger:
> On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
>> Mike Frysinger writes:
>>> i wish there was a way to use `wait` that didn't block until all the pids
>>> returned. maybe a dedicated option, or a shopt to enable this, or a new
>>> command.
>>>
Am 04.05.2012 21:13, schrieb Mike Frysinger:
> On Friday 04 May 2012 15:02:27 John Kearney wrote:
>> Am 04.05.2012 20:53, schrieb Mike Frysinger:
>>> On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
>>>> Mike Frysinger writes:
>>>>> i wish there wa
Am 04.05.2012 21:11, schrieb Greg Wooledge:
> On Fri, May 04, 2012 at 09:02:27PM +0200, John Kearney wrote:
>> set -m
>> cnt=0
>> trap ': $(( --cnt ))' SIGCHLD
>> set -- {0..20}
>> while [ $# -gt 0 ]; do
>> if [[ ${cnt} -lt 10 ]] ; th
Am 05.05.2012 06:35, schrieb Mike Frysinger:
> On Friday 04 May 2012 15:25:25 John Kearney wrote:
>> Am 04.05.2012 21:13, schrieb Mike Frysinger:
>>> On Friday 04 May 2012 15:02:27 John Kearney wrote:
>>>> Am 04.05.2012 20:53, schrieb Mike Frysinger:
>>>&g
Am 05.05.2012 06:28, schrieb Mike Frysinger:
> On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
>> On 5/4/12 2:53 PM, Mike Frysinger wrote:
>>> it might be a little racy (wrt checking cnt >= 10 and then doing a wait),
>>> but this is good enough for some things. it does lose visibility into
>>> wh
Am 06.05.2012 08:28, schrieb Mike Frysinger:
> On Saturday 05 May 2012 23:25:26 John Kearney wrote:
>> Am 05.05.2012 06:28, schrieb Mike Frysinger:
>>> On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
>>>> On 5/4/12 2:53 PM, Mike Frysinger wrote:
>>>>>
Am 06.05.2012 08:28, schrieb Mike Frysinger:
> On Saturday 05 May 2012 04:28:50 John Kearney wrote:
>> Am 05.05.2012 06:35, schrieb Mike Frysinger:
>>> On Friday 04 May 2012 15:25:25 John Kearney wrote:
>>>> Am 04.05.2012 21:13, schrieb Mike Frysinger:
>>>
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
The lib/sh/mktime.c module has a VMS specific include of
to pick up time_t.
On VMS, the time_t type is defined in the module.
So this VMS specific include can be removed.
Regards,
-John
ould give a list of $CODE/test1 $CODE/test2
when those directories exist, not "cd \$CODE/test".
If there is no fix in sight for this issue, can someone point me to a
guide for downgrading bash in recent popular Linux distros?
thanks,
--
John
On 06/11/2012 10:10 AM, Pierre Gaston wrote:
On Mon, Jun 11, 2012 at 10:59 AM, John Embretsen wrote:
On 27 Feb 2011 18:18:24 -0500, Chet Ramey wrote:
On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bugwrote:
A workaround is fine but is the 4.2 behavior bug or not?
It's a more-or-less unint
extent permitted by law.
I am running on 64-bit CentOS 6.
I have been writing a script that reads a text file and munges it to
create a shell command to run a script.
In two cases I wish to pass an array in the environment, like so:
14:28 john@Boomer$ STUFF[1]=one STUFFX=stuffx env | grep ^ST
Am 17.10.2012 03:13, schrieb Clark WANG:
> On Wed, Oct 17, 2012 at 5:18 AM, wrote:
>
>> Bash Version: 4.2
>> Patch Level: 37
>>
>> Description:
>>
>> bash -c 're=".*([0-9])"; if [[ "foo1" =~ ".*([0-9])" ]]; then echo
>> ${BASH_REMATCH[0]}; elif [[ "bar2" =~ $re ]]; then echo ${BASH_REMATCH[0]};
>>
Am 09.11.2012 17:21, schrieb Greg Wooledge:
> On Fri, Nov 09, 2012 at 11:18:24AM -0500, Greg Wooledge wrote:
>> restore_environment() {
>> set -o posix
>> eval "$saved_output_of_export_dash_p"
>> set +o posix
>> }
> Err, what I meant was:
>
> save_environment() {
> set -o posix
> saved_en
in bash 4.2 with a patch that adds a new "direxpand" option. Is this
the case? If so, is direxpand actually available in any released version
of bash yet (and if so which version)?
- John
In article , John
Caruso wrote:
> In bash 4.1, if you do "shopt +s dirspell" and type "ls /ect/passwd"
> it's corrected to "ls /etc/passwd". In bash 4.2 with dirspell enabled,
> the correction doesn't happen.
I forgot to mention that I've t
In article , Chet Ramey wrote:
> On 1/8/13 5:18 PM, John Caruso wrote:
>> In bash 4.1, if you do "shopt +s dirspell" and type "ls /ect/passwd"
>> it's corrected to "ls /etc/passwd". In bash 4.2 with dirspell enabled,
>> the correction doe
In article , Chet Ramey wrote:
> On 1/8/13 5:38 PM, John Caruso wrote:
>> So just to verify: there's no way in bash 4.2.0 through 4.2.28 to make
>> dirspell work correctly? The only fix is the direxpand option?
>
> Yes. Through 4.2.28, the dirspell option wil
In article , Chet Ramey wrote:
> On 1/9/13 1:27 PM, John Caruso wrote:
>> In article , Chet Ramey wrote:
>>> Yes. Through 4.2.28, the dirspell option will cause the filename to be
>>> rewritten with spelling correction internally, but the corrected filename
>&
Am 11.01.2013 19:38, schrieb Dan Douglas:
> $ set --; printf %q\\n "$@"
> ''
>
> printf should perhaps only output '' when there is actually a corresponding
> empty argument, else eval "$(printf %q ...)" and similar may give different
> results than expected. Other shells don't output '',
Am 11.01.2013 19:27, schrieb Dan Douglas:
> Bash treats the variable as essentially undefined until given at least an
> empty value.
>
> $ bash -c 'typeset -i x; [[ -v x ]]; echo "$?, ${x+foo}"; typeset -p x'
> 1,
> bash: line 0: typeset: x: not found
> $ ksh -c 'typeset -i x; [[ -
Am 11.01.2013 22:05, schrieb Dan Douglas:
> On Friday, January 11, 2013 09:39:00 PM John Kearney wrote:
>> Am 11.01.2013 19:38, schrieb Dan Douglas:
>>> $ set --; printf %q\\n "$@"
>>> ''
>>>
>>> printf should perhaps o
Am 11.01.2013 22:34, schrieb Dan Douglas:
> On Friday, January 11, 2013 09:48:32 PM John Kearney wrote:
>> Am 11.01.2013 19:27, schrieb Dan Douglas:
>>> Bash treats the variable as essentially undefined until given at least an
>>> empty value.
>>>
>>>
Am 12.01.2013 15:34, schrieb Dan Douglas:
> On Friday, January 11, 2013 10:39:19 PM Dan Douglas wrote:
>> On Saturday, January 12, 2013 02:35:34 AM John Kearney wrote:
>> BTW, your wrappers won't work. A wrapper would need to implement format
> Hrmf I should have clarif
Am 12.01.2013 14:53, schrieb Dan Douglas:
> Yes some use -u / -e for debugging apparently. Actual logic relying upon
> those
> can be fragile of course. I prefer when things return nonzero instead of
> throwing errors usually so that they're handleable.
ah but you can still do that if you want
Am 12.01.2013 20:40, schrieb Chet Ramey:
> On 1/12/13 9:48 AM, John Kearney wrote:
>
>> anyway now we have a point I disagree that
>> "${@}"
>>
>> should expand to 0 or more words, from the documentation it should be 1
>> or more. At least that
Am 13.01.2013 00:04, schrieb Chet Ramey:
> On 1/12/13 10:07 AM, John Kearney wrote:
>
>> regarding -e it mainly has a bad name because there is no good guide how
>> to program with it.
>> so for example this causes stress
>> [ ! -d ${dirname} ] && mkdir ${di
Am 14.01.2013 14:33, schrieb Greg Wooledge:
> On Sun, Jan 13, 2013 at 03:31:24AM +0100, John Kearney wrote:
>> set -o errexit
>> test_func() {
>> [ ! -d test ] && echo test2
>> }
>>
>> echo test3
>> test_func
>> echo test4
>>
Am 14.01.2013 20:25, schrieb Greg Wooledge:
> On Mon, Jan 14, 2013 at 08:08:53PM +0100, John Kearney wrote:
>> this should exit.
>> #!/bin/bash
>>
>> set -e
>> f() { test -d nosuchdir && echo no dir; }
>> echo testings
>> f
>> echo surviv
Am 14.01.2013 22:09, schrieb Ken Irving:
> On Mon, Jan 14, 2013 at 08:57:41PM +0100, John Kearney wrote:
>> ...
>> btw
>> || return $?
>>
>> isn't actually error checking its error propagation.
> Also btw, I think you can omit the $? in th
Am 14.01.2013 21:12, schrieb Chet Ramey:
> On 1/14/13 2:57 PM, John Kearney wrote:
>
>> I have no idea why errexit exists I doubt it was for lazy people
>> thought. its more work to use it.
> I had someone tell me one with a straight (electronic) face that -e
> exists `to
it's saved me an enormous
numbers of keystrokes over the years. There's nothing more frustrating
in bash than getting to (or worse, just past) "|" and realizing I need
to redirect stderr as well as stdout, then cursoring back and executing
a keyboard-acrobatic "2>&1" for the zillionth time
- John
In article , Chet Ramey wrote:
> On 1/17/13 1:01 PM, John Caruso wrote:
>> One feature of other shells (e.g. zsh and tcsh) I'd really love to have
>> in bash is "|&", which redirects both stdout and stderr--basically just
>> a shortcut for "2&g
ell as possible (though that's not as much of
a consideration these days as it used to be). But for interactive use
it's one of the greatest shell time- and effort-savers I know of, and
I'm very happy to hear it's made its way into bash. I wouldn't suggest
avoiding it unless you like carpal tunnel.
- John
1 - 100 of 278 matches
Mail list logo
