On 7/14/24 2:39 PM, Батунин Сергей wrote:
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
I entered the following commands:
cd
mkdir a
cd a
rmdir $PWD
cd .
This succeeds, because you can alway
On 07/27/2010 02:35 PM, Greg Wooledge wrote:
> On Tue, Jul 27, 2010 at 01:44:26PM +0200, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> http://mywiki.wooledge.org/BashFAQ/068
The process I want to put under the timeout does not
On Tue, Jul 27, 2010 at 01:44:26PM +0200, Christoph Dittmann wrote:
> What I was going for was a script which executes another command with a
> timeout.
http://mywiki.wooledge.org/BashFAQ/068
http://mywiki.wooledge.org/XyProblem
On 07/27/2010 02:05 PM, Eric Blake wrote:
> On 07/27/2010 05:44 AM, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> If you can assume the presence of GNU coreutils, use timeout(1). Much
> nicer for this particular task.
Thanks,
On 07/27/2010 05:44 AM, Christoph Dittmann wrote:
> What I was going for was a script which executes another command with a
> timeout.
If you can assume the presence of GNU coreutils, use timeout(1). Much
nicer for this particular task.
Otherwise, I did not review your script for accuracy.
--
On 07/27/2010 12:05 PM, Andreas Schwab wrote:
> If you want to kill the whole background job you need to enable job
> control (set -m) and call kill with the job specifier instead (kill %2
> in this case).
>
>> How can the wait call affect a job it's not supposed to wait for?
>
> It's a simple ra
Christoph Dittmann writes:
> Why is "sleep 5" still running in the second case even though the job
> received SIGTERM and is known to the job control as "terminated"?
Try adding "ps f" before the wait command to see the difference in how
bash executes the two cases. In the case without the brac
Le 15/04/2010 14:58, Clark J. Wang a écrit :
> I don't understand why the $string was still splitted into words since
> it's double quoted. Anyone can give a reasonable explanation?
set -x is often very good at giving explanations. Try this:
sh -x foo.sh
On Thu, Apr 15, 2010 at 09:58:42PM +0800, Clark J. Wang wrote:
> # cat foo.sh
> string=aa:bb:cc
> oldIFS=$IFS
> IFS=:
> for i in "$string"; do
> echo $i
> done
> IFS=$oldIFS
> # bash foo.sh
> aa bb cc
> #
>
> I don't understand why the $string was still splitted into words since
> it's double
"Clark J. Wang" writes:
> Look at following result:
>
> # cat foo.sh
> string=aa:bb:cc
> oldIFS=$IFS
> IFS=:
> for i in "$string"; do
> echo $i
> done
> IFS=$oldIFS
> # bash foo.sh
> aa bb cc
> #
>
> I don't understand why the $string was still splitted into words since
> it's double quoted.
I see. Thank you.
On Thu, Apr 15, 2010 at 10:05 PM, Greg Wooledge wrote:
> On Thu, Apr 15, 2010 at 09:58:42PM +0800, Clark J. Wang wrote:
>> # cat foo.sh
>> string=aa:bb:cc
>> oldIFS=$IFS
>> IFS=:
>> for i in "$string"; do
>> echo $i
>> done
>> IFS=$oldIFS
>> # bash foo.sh
>> aa bb cc
>> #
>>
On Monday 23 February 2009 07:31, Antonio Macchi wrote:
>>
>> Yes, it's ok. Posix says that printf field widths are specified in
>> number of bytes.
>>
>
> I've never red nothing about POSIX,
You should, especially if posting here something like that.
> but imho, in the past, "char" and
>
Yes, it's ok. Posix says that printf field widths are specified in number
of bytes.
I've never red nothing about POSIX, but imho, in the past, "char" and
"byte" was synonymous
maybe last POSIX definitions are very old...
Antonio Macchi wrote:
> same problem with read...
>
>
> LC_CTYPE="en_US.UTF-8"
>
> $ read -n1
> è
>
> $ hexdump -C <(echo -n $REPLY)
> c3|.|
> 0001
>
>
>
> "è" is two chars but read stops at the first
I fixed read to underst
On Sat, 2009-02-21 at 17:37 -0500, Chet Ramey wrote:
> Antonio Macchi wrote:
> >
> > thanks... but parameters expansions and printf builtin works differently
> > about it...
> >
> >
> >
> >
> > $ locale | grep LC_CTYPE
> > LC_CTYPE="en_US.UTF-8"
> >
> > $ a=eèèèe
> >
> > $ b=e
> >
> > $
Antonio Macchi wrote:
>
> thanks... but parameters expansions and printf builtin works differently
> about it...
>
>
>
>
> $ locale | grep LC_CTYPE
> LC_CTYPE="en_US.UTF-8"
>
> $ a=eèèèe
>
> $ b=e
>
> $ echo ${#a}
> 5
>
> $ echo ${#b}
> 5
>
> $ printf "*%-10s*" $a
> *eèèèe *
>
> $ p
Antonio Macchi wrote:
thanks... but parameters expansions and printf builtin works differently
about it...
same problem with read...
LC_CTYPE="en_US.UTF-8"
$ read -n1
è
$ hexdump -C <(echo -n $REPLY)
c3|.|
0001
"è" is two
thanks... but parameters expansions and printf builtin works differently
about it...
$ locale | grep LC_CTYPE
LC_CTYPE="en_US.UTF-8"
$ a=eèèèe
$ b=e
$ echo ${#a}
5
$ echo ${#b}
5
$ printf "*%-10s*" $a
*eèèèe *
$ printf "*%-10s*" $b
*e *
is it ok?
Antonio Macchi wrote:
>
> $ a=$'\xd9\xbf'
>
> $ echo ${#a}
> 1
>
> $ a2=${a:0:1}
>
> $ echo ${#a2}
> 1
>
>
>
>
> this two characters are "j" and "k" graphical characters in linux
> terminal/console
>
> I need to extract only one... but apparently I can't.
Those two bytes happen to compos
Antonio Macchi wrote:
$ a=$'\xd9\xbf'
$ echo ${#a}
1
$ a2=${a:0:1}
$ echo ${#a2}
1
ops... I mean...
$ a2=${a:0:1}
$ hexdump -C <(echo $a2)
d9 bf 0a |...|
0003
seems bash can't break this two characters...
20 matches
Mail list logo
