Changes to `arg' - Bug in #! processing & "pear broken..."

From: Garance A Drosehn (gad_at_FreeBSD.org)
Date: 06/10/05

  • Next message: Jeff Roberson: "Re: RFC: Stack saving/tracing functionality." 
    Date: Fri, 10 Jun 2005 15:37:46 -0400
To: freebsd-arch@FreeBSD.org, freebsd-ports@FreeBSD.org

    As most people are probably tired of hearing, I recently changed the
    way the kernel parses #!-lines in shell scripts. This solves some
    problems with scripts that only break on FreeBSD, but it also
    removed some nice flexibility that FreeBSD has supported for many
    years now.

    I now propose to re-implement that flexibility (and more!) via some
    changes to the `env' command. The changes add three new (non-standard)
    options to `env'. Right now all three are wrapped up in a single
    update, but then the options are somewhat tied together. I could
    split them apart for committing.

    I'd like to commit these changes to 6.0, and they should also be fine
    to MFC to 5.x. They do not depend on the change in kernel-parsing
    (and *that* parsing-change will *not* be MFC-ed!).

    The three new options are:
         -v -- Turns up a verbosity setting, useful for seeing
                      what `env' is doing. Particularly useful for
                      debugging the following options.
        -S string -- "split string on spaces". The idea is to take
                      a single string, split it into separate arguments,
                      and then process those arguments. This supports
                      single-quoted strings, double-quoted strings, and
                      a few other features that the previous parsing
                      code was never going to support.
        -P altpath -- specify a path list to use when searching for the
                      'utility' (program to execute). `env' does the
                      search itself, without checking or changing the
                      present value of PATH. This was implemented by
                      copying a few routines from the `which' command.

    Note that due to the parsing-change in 6.0, the -P option is
    pretty much worthless for scripts in 6.0 without the -S option.

    These options would then let you have a script start with:

        #!/usr/bin/env -S /usr/local/bin/php -n -q -dsafe_mode=0

    which would work exactly the way that:

        #!/usr/local/bin/php -n -q -dsafe_mode=0

    does in 5.x-stable. They would also let you have a script which
    starts with:

        #!/usr/bin/env -S -P/usr/local/bin:/usr/bin perl

    and the script will execute /usr/local/bin/perl or /usr/bin/perl,
    without caring about the present setting for PATH=, and without
    changing what value the script will see for PATH= when it executes.

    All of new options put together will just about double the size
    of `env' on my system:

    i386:
          root wheel 4184 Jun 10 01:08 /usr/bin/env*
          root wheel 7360 Jun 10 14:31 /usr/bin/env-rel6*
    ppc:
          root wheel 8948 Jun 6 01:58 /usr/bin/env*
          root wheel 11912 Jun 10 14:28 /usr/bin/env-rel6*
    sparc:
          root wheel 6040 Jun 10 14:51 /usr/bin/env*
          root wheel 10008 Jun 10 14:52 /usr/bin/env-rel6*

    It does compile with WARNS=6 on the above three platforms, but
    then it did that before I started.

    The actual update is presently over 300 lines, so I'll just include
    a pointer to it:
    http://people.freebsd.org/~gad/env-rel6.diff

    It has only had some light testing, so I'm sure there's at least a
    few bugs in there somewhere. I have not made any changes to the man
    page yet, but the comments should give you a good idea of how I
    *mean* for it to work.

    So, is this overkill? I think these features would be useful... 

    -- 
Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
Senior Systems Programmer               or   gad@FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Jeff Roberson: "Re: RFC: Stack saving/tracing functionality."

    Relevant Pages

    • Re: Is a "group" profile possible?
      ... Be careful with setting 'ENV' -- it may, in some cases, cause the ... some of the applications auxiliary binaries (called in the scripts) could ... And there was a .cshrc file (created by ...
      (comp.unix.shell)
    • /usr/bin/env program broken
      ... I run some scripts with env as the first line, ... but this does not seem to work under Solaris 9. ... and env is in /usr/bin and python is ...
      (comp.unix.solaris)
    • Force Commit Record
      ... I have an issue with users not committing their records. ... me from making adjustments to the database (defining fields), ... validation issues when they run scripts and causes basic confusion ("I ...
      (comp.databases.filemaker)
    • Re: PS1 prompt set prior to /etc/profile
      ... there aren't any PS1 lines in there. ... scripts being called from the ~/.profile. ... In any event, putting "env" ... profile. ...
      (comp.unix.solaris)
    • Re: another users env.
      ... Is there a way of finding out another (non-root) user's env. ... run the same scripts as them ... add a line to some script the run to dump them. ...
      (alt.os.linux)