Re: Need help correcting this Bash function

From: Chris F.A. Johnson (cfajohnson_at_gmail.com)
Date: 10/09/04 

Date: 9 Oct 2004 14:03:31 GMT

On 2004-10-09, Tavis Ormandy wrote:
> On 2004-10-09, Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
>>> Re-read the thread, I was asking why is it necessary to add extra code
>>
>> Who said anything about adding extra code?
>
> What do you think we are discussing here?

    You brought up the issue of extra code; my scripts generally do
    not need extra code to be portable or efficient.

>>> so that some antiquated implementations don't get confused in some rare
>>> situation that is never going to happen anyway, as he's WRITING A BASH
>>> SCRIPT.
>>
>> Why is it better to write a bash script than a script that runs
>> equally well in bash, ksh, ash, and other POSIX shells?
>
> Stop. Read Thread. Think.
>
> You seem to think I'm advocating non-portability. I'm saying why should
> exta code be added to my conditions to support antiquated, broken
> shells? _especially_ as this script is a bash script.

     You are the only one suggesting that it requires extra code.

     IT DOESN'T!

>>>> Pattern matching is available with case; [[..]] is not necessary (I
>>>> have NEVER used it in a script).
>>>
>>> Well, your scripts must be needlessly complex and long.
>>
>> No, they are usually not any longer than a less portable script.
>
> Well then, you're lucky that you only ever have to do simple operations.

     On the contrary, I often do complex operations.

>> I am putting together a collection of scripts that will run in
>> any POSIX shell. When there is a shorter or faster way using a
>> bash or ksh93 feature, I add that as an alternative. You'd be
>> surprised how few there are.
>
> Why do you think these features were added?
>
> David Korn was feeling bored one day?

     Many of the features that Korn added are found in all POSIX
     shells (that's what the POSIX standard was based on).

> Because people wanted them.
>
>> There are some things I would not try to do in anything other
>> than bash (or, perhaps, ksh93). For example, in another thread
>> (pointing best size directories...) I posted a script that is
>> bash specific, because it is more efficient.
>
> So...what is your point?
>
> a) Everyone should write 100% POSIX sh compliant code.
> b) Everyone should write 100% POSIX sh compliant code, unless it's easier not to.

     Do you have any idea what is and is not POSIX?

>>> But if the satisfaction that should you distribute your script to
>>> anyone, the 0.001% of people out there running
>>> foosh-0.892-patchlevel42_rc3 on a VAX that hasnt been updated in 30
>>> years makes up for that, good for you.
>>
>> If it gives you satisfaction to write code that will be hard to
>> use an another system when you could have written code that
>> would run there without any loss of efficiency, good for you.
>
> Yes, hard to use on another system that has been trapped in stasis for
> 20 years.

     This has nothing to do with old systems. The POSIX shell is a
     relatively recent development.

     There are other reasons that it may not be possible to use bash
     (or ksh93, or whatever):

        I am not the sysadmin, the sysadmin will not install it, and I
        do not have access to a compiler.

        This system is shoehorned into a tiny box; it only has the
        stripped-down shell, ash, which is a POSIX shell. There's not
        room for anything else.

        etc.......

> It gives me satisfaction to take advantage of all the new features
> designed to make my scripts more powerful, efficient, and easier to
> write.

    And when it does make the script more powerful and efficient I use
    them. That, however, is not as common as one might expect.

>>> Why do you think these new features are added? to force users into an
>>> upgrade path? No, beacuse they are useful.
>>
>> Why is [[...]] any better than case ... esac for the same
>> functionality?
>
> * the code is already an if construction, rewriting it as a case
> statement requires additional effort.
> * [[..]] allows for future expansion that case cannot provide.
>
>> Why is [[...]] any better than [...] for the same functionality?
>
> If you think [..] provides the same functionality as [[..]], you need to
> check the documentation.

    That's not what I said. I know there are differences. Those
    differences are rarely needed. If those occasions occurred, I
    would use it.

>>>>> You're taking this out of context, I'm all for portability, but he's
>>>>> writing a bash script, why not use the features that every modern shell
>>>>> written in the last decade has and could genuinely be useful here?
>>>>
>>>> I do use those which are POSIX-compliant and common to those
>>>> shells. I don't use those which are limited to one or two shells
>>>> unless it makes a significant difference to the task at hand
>>>> because as I said before, I might want to use the script on a
>>>> machine which doesn't have bash, and on which I cannot install it.
>
> [[..]] isn't bash specific, all modern shells have it. It's a ksh93
> feature, I believe.

    Not all modern shells have it. Ash doesn't; *BSD sh doesn't. It's
    not a POSIX contruction.

>>> Very true, you might also fall through a time portal and need to run it
>>> in 1976. Now that you mention it, I'm pretty outraged people are using
>>> perl5 features in their perl scripts, what if someone out there is still
>>> on perl4?!?!??!
>>
>> I'm outraged that people are using any version of perl! ;)
>>
>>> won't somebody, please, think of the children!
>>
>> ????
>
> It's a quote from the simpsons, everytime there is a moral issue in the
> town, one of the characters always says this. It was a joke :)
>
>> Why use a bus if a compact car will do the job?
>
> You mean, why use a ferrari when a bicycle will do the job?

    No, I don't. Most of the time I don't need the extras to write an
    efficient, compact script, even a complex one.

>> When did you last use it in a situation where case would not have
>> been just as efficient?
>
> Today.

    Example? 

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

Relevant Pages

  • Re: POSIX compilant function call
    ... In this script there is a function call lile this: ... The above happens to be POSIX and *not* bash. ... It redirects the standard output of getmounts to the file whose ...
    (comp.unix.shell)
  • Re: POSIX compilant function call
    ... In this script there is a function call lile this: ... The above happens to be POSIX and *not* bash. ... It redirects the standard output of getmounts to the file whose ...
    (comp.unix.shell)
  • Re: csh question: foreach
    ... >>either ash, ksh or bash). ... >>compatible with the Bourne shell, and the Bourne shell is not ... > as well as Bugs that let him deviate from the POSIX ... >>have a script working on moddern Unices. ...
    (comp.unix.shell)
  • Re: csh question: foreach
    ... >>either ash, ksh or bash). ... >>compatible with the Bourne shell, and the Bourne shell is not ... > as well as Bugs that let him deviate from the POSIX ... >>have a script working on moddern Unices. ...
    (comp.unix.solaris)
  • Re: function definition syntax
    ... :>:>: The latter is POSIX, as well as portable to Bourne shell. ... Or you want to IFS parse without having to save ... In which case it might as well be a separate script - you don't need a function. ... On every POSIX shell I've seen, though I don't thik it's a POSIX ...
    (comp.unix.shell)