Stupid bash question
 

The "&&" says "if the previous command was successful, do the following
command. So, if you have a command "isthislinux" on your machine (I do
not) and it returns the string "LINUX" it will issue the ulimit command.
If you do not have that command or the command returns something else,
it will not.


So, the short answer is: yes


-------- Original Message --------
Subject: Stupid bash question
From: aragonx@dcsnow.com
To: fedora-list@redhat.com
Date: 12/10/2007 03:29 PM


Okay, I'm confused. How would bash interpret this line?

[ "`isthislinux`" = "LINUX" ] && ulimit -S -n 65536

Would that be teh same as:

if [ "`isthislinux`" == "LINUX" ]
then
ulimit -S -n 65536
fi

This is quite confusing to me.



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

aragonx@dcsnow.com wrote:
> Okay, I'm confused. How would bash interpret this line?
>
> [ "`isthislinux`" = "LINUX" ] && ulimit -S -n 65536
>
> Would that be teh same as:
>
> if [ "`isthislinux`" == "LINUX" ]
> then
> ulimit -S -n 65536
> fi
>
> This is quite confusing to me.
>
One thing that would probably help your understanding is that [ is
actually a command. It is usually a shell built-in command, but it
is also a command in /usr/bin, and is the same as the test command.

You may want to read the bash man page. It covers the [ command, as
well as how && and || are processed by the shell.

Mikkel
--

Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

On Mon, 2007-12-10 at 15:48 -0700, Paul Lemmons wrote:
> The "&&" says "if the previous command was successful, do the following
> command. So, if you have a command "isthislinux" on your machine (I do
> not) and it returns the string "LINUX" it will issue the ulimit command.
> If you do not have that command or the command returns something else,
> it will not.
>
> So, the short answer is: yes
>
>
> -------- Original Message --------
> Subject: Stupid bash question
> From: aragonx@dcsnow.com
> To: fedora-list@redhat.com
> Date: 12/10/2007 03:29 PM
>
> > Okay, I'm confused. How would bash interpret this line?
> >
> > [ "`isthislinux`" = "LINUX" ] && ulimit -S -n 65536
Shouldn't the operator above be ==
> >
> > Would that be teh same as:
> >
> > if [ "`isthislinux`" == "LINUX" ]
> > then
> > ulimit -S -n 65536
> > fi
> >
> > This is quite confusing to me.
> >
> >
> >
> --
> fedora-list mailing list
> fedora-list@redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
================================================== =====================
Onward through the fog.
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

On Tue, 2007-12-11 at 09:30 -0600, Aaron Konstam wrote:
> On Mon, 2007-12-10 at 15:48 -0700, Paul Lemmons wrote:

> > > Okay, I'm confused. How would bash interpret this line?
> > >
> > > [ "`isthislinux`" = "LINUX" ] && ulimit -S -n 65536
> Shouldn't the operator above be ==

No, '=' is "test"'s POSIX/ISO/IEEE-standardized string comparison
operator (c.f. man test).

'==' is a bash-specific, non-standardized extension to "test".
/bin/sh scripts should not use '=='.

Ralf


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

Mikkel L. Ellertson wrote:

One thing that would probably help your understanding is that [ is
actually a command. It is usually a shell built-in command, but it
is also a command in /usr/bin, and is the same as the test command.
...


Mmm, curious. I wonder why are they /not/ the same command?

$ type [ test
[ is a shell builtin
test is a shell builtin
$ ls -li /usr/bin/{[,test}
1234416 -rwxr-xr-x 1 root root 31404 2007-12-05 08:25 /usr/bin/[
1234972 -rwxr-xr-x 1 root root 29032 2007-12-05 08:24 /usr/bin/test

I always thought that [ and test were links to the same binary.

I guess disk blocks aren't as precious as they once were ;-)

<Joe

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

Joe Smith wrote:
> Mikkel L. Ellertson wrote:
>> One thing that would probably help your understanding is that [ is
>> actually a command. It is usually a shell built-in command, but it
>> is also a command in /usr/bin, and is the same as the test command.
>> ...
>
> Mmm, curious. I wonder why are they /not/ the same command?
>
> $ type [ test
> [ is a shell builtin
> test is a shell builtin
> $ ls -li /usr/bin/{[,test}
> 1234416 -rwxr-xr-x 1 root root 31404 2007-12-05 08:25 /usr/bin/[
> 1234972 -rwxr-xr-x 1 root root 29032 2007-12-05 08:24 /usr/bin/test
>
> I always thought that [ and test were links to the same binary.
>
> I guess disk blocks aren't as precious as they once were ;-)
>
> <Joe
>
I do too. The last time I had checked there were the same command. I
guess I should have double checked before posting. It looks like
test was changed so you do not need the [ ]. You can use something
like "test $DISPLAY && echo DISPLAY is set." but not
"[ $DISPLAY && echo DISPLAY is set." or even [ $DISPLAY ] && echo
DISPLAY is set.". I guess the test man page needs to be updated, and
maybe a man page added for [.

Mikkel
--

Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

>
> On Tue, 2007-12-11 at 09:30 -0600, Aaron Konstam wrote:
>> On Mon, 2007-12-10 at 15:48 -0700, Paul Lemmons wrote:
>
>> > > Okay, I'm confused. How would bash interpret this line?
>> > >
>> > > [ "`isthislinux`" = "LINUX" ] && ulimit -S -n 65536
>> Shouldn't the operator above be ==
>
> No, '=' is "test"'s POSIX/ISO/IEEE-standardized string comparison
> operator (c.f. man test).
>
> '==' is a bash-specific, non-standardized extension to "test".
> /bin/sh scripts should not use '=='.
>
> Ralf

Thank you everyone for your help again.

BTW, is there a bash email list? If not, is there a need for one?




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

On 11/12/2007, aragonx@dcsnow.com <aragonx@dcsnow.com> wrote:
Thank you everyone for your help again.

BTW, is there a bash email list?**If not, is there a need for one?


I've no idea whether there is a bash mailing list, but I've always found the Advanced Bash Scripting Guide to be very helpful.

http://www.tldp.org/LDP/abs/html/




--
Regards,
Derek
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

At 12:05 PM -0500 12/11/07, Joe Smith wrote:
>Mikkel L. Ellertson wrote:
>> One thing that would probably help your understanding is that [ is
>> actually a command. It is usually a shell built-in command, but it
>> is also a command in /usr/bin, and is the same as the test command.
>> ...
>
>Mmm, curious. I wonder why are they /not/ the same command?
>
>$ type [ test
>[ is a shell builtin
>test is a shell builtin
>$ ls -li /usr/bin/{[,test}
>1234416 -rwxr-xr-x 1 root root 31404 2007-12-05 08:25 /usr/bin/[
>1234972 -rwxr-xr-x 1 root root 29032 2007-12-05 08:24 /usr/bin/test
>
>I always thought that [ and test were links to the same binary.
>
>I guess disk blocks aren't as precious as they once were ;-)

The reason seems weak to me, but test does not require a closing square
bracket, while [ does, and:

At 6:22 PM +0200 5/11/07, Stepan Kasal wrote:
>Hi,
>
>On Fri, May 11, 2007 at 04:44:39PM +0200, Matthias Saou wrote:
>> single square brackets, I thought "[" was a symlink to the
>> coreutils "test" command, [..]
>
>AFAIK, it used to be hard link, not symlink.
>
>> -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[
>> -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test
>
>GNU Coding Standards now declare that the behaviour of binary
>should not depend on its name.
--
__________________________________________________ __________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Stupid bash question
 

Tony Nelson wrote:
> The reason seems weak to me, but test does not require a closing
> square bracket, while [ does, and:
> ...
>> GNU Coding Standards now declare that the behaviour of binary
>> should not depend on its name.

From http://www.gnu.org/prep/standards/html_node/User-Interfaces.html:

Please don't make the behavior of a utility depend on the name used to
invoke it. It is useful sometimes to make a link to a utility with a
different name, and that should not change what it does.


Sounds more like a request than a declaration ;-)

I wish they had provided some rationale, seeing as how the practice has
a long history on Unix, and I (at least) have not run into any situation
where it caused a problem.


Requiring the closing bracket or not seems like a trivial difference in
behavior, no?


Yep, I'll go with 'weak' as well.

Over a few hundred systems, this must be wasting almost a penny's worth
of space.


<Joe

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list