On Tue, Mar 29, 2011 at 3:09 AM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>
>> On Mon, Mar 28, 2011 at 10:53:21AM -0700, Linda Walsh wrote:
>>
>>> if [ ! -e $d/S??sshd ]; then echo "sshd not enabled"; fi
>>>
>>
>> That will fail quite colorfully if the glob matches multiple files.
>> (Also,
On 28.03.2011 18:03, tytus64 wrote:
[...]
trap "" HUP; cat $log_file | {
while read line
[...]
useless use of cat!
while read ... < file
no need for a subshell actually (introducted by the pipe).
Hey, if one doesn't ask...
Chet Ramey wrote:
I don't think implementing an option to disable that is a good use of
time.
Chet
On 3/28/11 1:53 PM, Linda Walsh wrote:
>
>
>
> Is it possible to have an 'Option' to make '[[' compatible
> with '[', w/rt pathname expansion?
Anything's possible. Likely? No.
> It seems counter-intuitive to have:
>
> d="/etc/rc.d/rc5.d"
> if [[ ! -e $d/S??sshd ]]; then echo "sshd not enabl
Greg Wooledge wrote:
On Mon, Mar 28, 2011 at 10:53:21AM -0700, Linda Walsh wrote:
if [ ! -e $d/S??sshd ]; then echo "sshd not enabled"; fi
That will fail quite colorfully if the glob matches multiple files.
(Also, "$d" should be quoted.)
---
If, in 30 years of unix experience, I'd ever see
On 3/28/11 12:03 PM, tytus64 wrote:
> OK. Thanks everybody for their input. Really appreciate all the answers. I
> modified the first loop as follows to get the subshell to ignore HUP signal:
>
>
> trap "" HUP; cat $log_file | {
> while read line
> do
> line_num=`expr $line_num + 1
On Mon, Mar 28, 2011 at 2:25 PM, Greg Wooledge wrote:
> In any case, I see no benefit to changing how [[ works. A change would
> just cause more confusion.
and probably break many existing scripts
-mike
On Mon, Mar 28, 2011 at 10:53:21AM -0700, Linda Walsh wrote:
> if [ ! -e $d/S??sshd ]; then echo "sshd not enabled"; fi
That will fail quite colorfully if the glob matches multiple files.
(Also, "$d" should be quoted.)
On IRC we recommend enabling nullglob, pulling the results of the glob
into an
> On 03/28/2011 06:56 PM, Matias A. Fonzo wrote:
>>
>> I have bash 4.2.8(2)-release with readline 6.2 running on GNU/Linux.
>>
>> I've exported a variable and when I press TAB, the result is a
>> backslash.
>> For example, with the case of the $HOME variable:
>>
>> $ mkdir $HOME/test
>> $ cd $HOME/
Is it possible to have an 'Option' to make '[[' compatible
with '[', w/rt pathname expansion?
It seems counter-intuitive to have:
d="/etc/rc.d/rc5.d"
if [[ ! -e $d/S??sshd ]]; then echo "sshd not enabled"; fi
give different output than:
if [ ! -e $d/S??sshd ]; then echo "sshd not enabled";
On 03/28/2011 06:56 PM, Matias A. Fonzo wrote:
Hi there,
I have bash 4.2.8(2)-release with readline 6.2 running on GNU/Linux.
I've exported a variable and when I press TAB, the result is a backslash.
For example, with the case of the $HOME variable:
$ mkdir $HOME/test
$ cd $HOME/test
The resu
Hi there,
I have bash 4.2.8(2)-release with readline 6.2 running on GNU/Linux.
I've exported a variable and when I press TAB, the result is a backslash.
For example, with the case of the $HOME variable:
$ mkdir $HOME/test
$ cd $HOME/test
The result is:
cd \$HOME/test
Instead of showing the f
Chet Ramey wrote:
>
>
> Sure. Trap it to SIG_IGN: `trap "" SIGHUP'.
>
>
OK. Thanks everybody for their input. Really appreciate all the answers. I
modified the first loop as follows to get the subshell to ignore HUP signal:
trap "" HUP; cat $log_file | {
while read line
do
On 3/28/11 11:39 AM, tytus64 wrote:
>> There is a bash process that is forked to execute the `while read ...'
>> in the first pipeline loop. It has to hang around the whole time, so it
>> can run the while loop and exit with the correct status. If you send it
>> a SIGHUP with `killall bash', it
Chet Ramey wrote:
>
> There is a bash process that is forked to execute the `while read ...'
> in the first pipeline loop. It has to hang around the whole time, so it
> can run the while loop and exit with the correct status. If you send it
> a SIGHUP with `killall bash', it will exit.
>
Tha
On 3/28/11 9:59 AM, tytus64 wrote:
>
> Interesting...
> I used kill -HUP instead of killall -HUP and it works
> without interrupting the first loop. I also noticed 2 processes running when
> the first loop is iterating but only 1 when the second loop is iterating:
There is a bash process that
On Mon, Mar 28, 2011 at 06:59:23AM -0700, tytus64 wrote:
>
> Interesting...
> I used kill -HUP instead of killall -HUP and it works
> without interrupting the first loop. I also noticed 2 processes running when
> the first loop is iterating but only 1 when the second loop is iterating:
>
> $ p
Interesting...
I used kill -HUP instead of killall -HUP and it works
without interrupting the first loop. I also noticed 2 processes running when
the first loop is iterating but only 1 when the second loop is iterating:
$ ps -ef |grep
bla 3711 2671 0 09:50 pts/000:00:00 /bin/bash ./
bl
On 3/28/11 9:12 AM, tytus64 wrote:
>
>
> Chet Ramey wrote:
>>
>> On 3/25/11 5:25 PM, tytus64 wrote:
>>
>> You don't say anything about what version of bash you're using or what OS
>> you're on, but I couldn't reproduce it.
>>
>>
>>
>
> I am running Fedora release 13 (Goddard) with GNU bash, vers
Chet Ramey wrote:
>
> On 3/25/11 5:25 PM, tytus64 wrote:
>
> You don't say anything about what version of bash you're using or what OS
> you're on, but I couldn't reproduce it.
>
>
>
I am running Fedora release 13 (Goddard) with GNU bash, version
4.1.7(1)-release (x86_64-redhat-linux-gnu).
On Fri, Mar 25, 2011 at 02:25:35PM -0700, tytus64 wrote:
> while read line
> do
> line_num=`expr $line_num + 1`
> echo $line_num: $line >> ./out.log
> done < $log_file
Although it's not directly related to your question, I feel obliged
to point out that you can increment a variable without
21 matches
Mail list logo
