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
Configuration Information
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=.
-fstack-protector-strong -Wformat ->
uname output: Linux bab-VirtualBox 5.15.0-87-generic #97~20.04.1-Ubuntu
SMP Thu Oct 5 08:
Hello,
consider the following snippet:
EXTENSION=png
INPUT_FILES=*.$EXTENSION
If there are for example 3 input files, an echo delivers:
echo $INPUT_FILES --> '01.png 02.png 03.png'
No we change the EXTENSION:
EXTENSION=jpg
Now, in a dir without jpg files the following happens:
INPUT_FILES=
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
Hi,
consider the following script:
#!/bin/bash
sleep 0.5 &
if [[ $1 = a ]]; then
sleep 5 &
else
{ sleep 5; } &
fi
PID=$!
wait %1
kill $PID
ps aux | grep '[s]leep 5'
exit 0
When I run this script with parameter "a" I get the following output:
./foo.sh: line 11: 12132 Terminated
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
>> #
>>
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. Anyone can give a reasonable explanation?
-Clark
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...
$ 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.
25 matches
Mail list logo
