[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ver_linux script
    On Mon, Mar 13, 2000 at 09:07:43AM +0000, Riley Williams wrote:
    > Hi Tim, Alan.
    > >>> alias ls='ls -F'
    > >>> . ver_linux
    > >> alias make='echo banana'
    > >> make bzImage
    > >> That doesnt work either ..
    > Is that really a fair comparison? I know quite a few people who
    > use the alias I quoted, along with several others. Quite a common
    > alias for the above command on Linux systems is...

    It's somewhat fair, but a bit exaggerated.

    > [...]
    > My reading of that file is that it tries to use whichever version
    > of each command is nearest in the path, and unless I'm wrong, the
    > `make` command does not respect aliases, but does respect the
    > PATH variable, and it was for this reason that none of the
    > commands therein use paths. I tried to keep that behaviour.

    I don't know about this, but if it's true then you're right,
    using /bin/ls might be the Wrong Thing[tm] to do.

    > I've checked now, and indeed it can't work as written, but the
    > following alternative diff does exactly what was intended and has
    > been verified through long years of use. This is the variant I
    > was actually using:
    > [patch snipped]

    This doesn't work for me either. It seemed to do the same thing
    that the regular ver_linux script does.

    I'm not sure if I'm getting the same problem you are.
    Normally I get

    Linux C Library 2.1.3

    but with ls aliased to 'ls -F', I get

    Linux C Library*

    even with the patch you suggested.

    > The key to it doing what is required are the brackets, which
    > cause the enclosed to be run in a separate subshell and thus
    > insulate it from the calling environment.


    > > Seriously though, Alan, I think it's useful to see what
    > > version the kernel has been compiled with, so I've written
    > > up a patch against 2.3.51 which uses /proc/version instead
    > > of "uname -a" (provided that you have /proc/version, of
    > > course).
    > Probably a better idea would be to provide both.

    Well, /proc/version provides most of the same information
    that uname -a provides. The only things missing are the
    machine type and processor type.

    Perhaps a line like
    cat /proc/version; echo -n "Processor: "; uname -mp
    would be enough.

    > > I've included the change to use "/bin/ls" instead of just
    > > ls, which seems to fix the weird behaviour that Riley
    > > describes.
    > It could also prevent the script from producing the correct
    > answers in some cases, so I would suggest basing a replacement
    > on the application of the above diff to the original version.

    It would? The only instance I can think of would be when
    ls is not in /bin. Please provide an example.

    Tim Coleman <>
    Software Developer/Systems Administrator/RDBMS Specialist/Linux Advocate
    University of Waterloo Honours Co-op Combinatorics & Optimization
    Finger for GnuPG public key
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 13:57    [W:0.024 / U:17.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site