On Thu, Dec 9, 2010 at 7:11 PM, Richard wrote:
> Hi!
>
> OS X 10.6.x
>
> I am trying to loop over some files with extended characters.
> Everything works fine if I hardcode the path, see example 1,
> but if I use a for loop with a * wildcard, I get some problems,
> see example 2.
>
> The problems
On 12/9/10 11:30 AM, Eric Blake wrote:
> On 09/23/2010 10:47 AM, Keith Thompson wrote:
>> I'm not sure whether this is a bug (the documentation doesn't address
>> this case), but it's at least mildly annoying.
>>
>> If you invoke the "cd" commands with extra arguments after the directory
>> name, a
Hi!
OS X 10.6.x
I am trying to loop over some files with extended characters.
Everything works fine if I hardcode the path, see example 1,
but if I use a for loop with a * wildcard, I get some problems,
see example 2.
The problems seems to be that the extended character -- é -- in the
hardcoded
Hi!
OS X 10.6.x
I am trying to loop over some files with extended characters.
Everything works fine if I hardcode the path, see example 1,
but if I use a for loop with a * wildcard, I get some problems,
see example 2.
The problems seems to be that the extended character -- é -- in the
hardcoded
On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy wrote:
> Hello,
>
> With a simple script such as that below, bash can enter an infinite loop of
> eating memory until the system is rendered unusable:
>
> #!/bin/bash
> PATH=~
> infinitely-recurse
>
> Save this as infinitely-recurse in your home dire
I have a script that I wrote and use successfully on FreeBSD with bash
version 4.1.9(0)-release (amd64-portbld-freebsd8.1). The script uses a
redirection "2>/dev/null" in several places. For some reason, that
does not seem to be working correctly under an old version of bash;
i.e. GNU bash, version
"john.ruckstuhl" writes:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
[[ ... ]] uses the same operators as test, so if you want numeric
comparison you need to use -gt, -lt, etc.
> Which part of the documentation would set me straight?
$ help [[
Andreas.
--
Andreas
On Sat, Nov 20, 2010 at 2:45 AM, john.ruckstuhl
wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight? If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 20
On 09/23/2010 10:47 AM, Keith Thompson wrote:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
>
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments are silently ignored.
>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:
> In bash, a comparison in
On Thu, Dec 9, 2010 at 10:48 AM, Dennis Williamson
wrote:
> On Fri, Nov 19, 2010 at 6:45 PM, john.ruckstuhl
> wrote:
>> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
>> This isn't what I expected.
>> Which part of the documentation would set me straight? If someone
>> coul
Diggory Hardy wrote:
> With a simple script such as that below, bash can enter an infinite
> loop of eating memory until the system is rendered unusable:
>
> #!/bin/bash
> PATH=~
> infinitely-recurse
Yes, of course. It calls itself repeatedly and every copy consumes
just a little more system res
On Fri, Nov 19, 2010 at 6:45 PM, john.ruckstuhl
wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight? If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 20
On Fri, Nov 19, 2010 at 04:45:15PM -0800, john.ruckstuhl wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
Correct. Assuming you use the string-comparison operators (> and <)
rather than the integer-comparison operators (-gt, -lt, etc.).
> $ if [[ 1000 > 200 ]]; then
In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
This isn't what I expected.
Which part of the documentation would set me straight? If someone
could quote the fine manual, that would be great.
$ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
pass
$ if [[ 1000 > 200
Keith Thompson writes:
> "Illia Bobyr" writes:
> [...]
>> When I do "gitk &" upon gitk exit the parent bash process
>> terminates as well.
>> When I do "(gitk &)" it works fine. There does not seem to be any
>> crash dumps. But sometimes bash outputs "Logout" before it exits just
>
"Illia Bobyr" writes:
[...]
> When I do "gitk &" upon gitk exit the parent bash process
> terminates as well.
> When I do "(gitk &)" it works fine. There does not seem to be any
> crash dumps. But sometimes bash outputs "Logout" before it exits just
> as if I would press ^D on promp
Keith Thompson writes:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
>
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments are silently ignored.
[description snipped]
I'm not sure whether this is a bug (the documentation doesn't address
this case), but it's at least mildly annoying.
If you invoke the "cd" commands with extra arguments after the directory
name, all the extra arguments are silently ignored.
I noticed this when I accidentally typed a '/' when I m
On 29.07.2010 22:55, Bernd Eggink wrote:
It seems that indirect expansion doesn't work with arrays:
$ a=(x y z)
$ b=a
$ echo "${!b[0]} ${!b[1]} ${!b[2]}"
x
Is that intended? The documentation isn't explicit about it.
IMHO it would be very desirable to have a indirect expansion facility
for arr
Maybe I'm doing something wrong, but the following will make bash
crash.
terminal 2:
$ mkfifo test
$ while true; do echo foo && sleep 1; done > test
terminal 1:
$
Hello,
With a simple script such as that below, bash can enter an infinite loop of
eating memory until the system is rendered unusable:
#!/bin/bash
PATH=~
infinitely-recurse
Save this as infinitely-recurse in your home directory and run - and make sure
you kill it pretty quick. OK, so an obvio
On Dec 7, 2010, at 6:02 PM, Eric Blake wrote:
> [adding the Austin Group]
>
> On 12/07/2010 06:19 PM, Chet Ramey wrote:
>> On 12/7/10 11:12 AM, Roman Rakus wrote:
>>> This one is already reported on coreutils:
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574
>>>
>>> The problem is with
On 12/08/2010 02:19 AM, Chet Ramey wrote:
On 12/7/10 11:12 AM, Roman Rakus wrote:
This one is already reported on coreutils:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574
The problem is with numbers higher than /0377; echo and printf consumes all
3 numbers, but it is not 8-bit number.
24 matches
Mail list logo
