Re: [FYI] Re: Vulnerability in libtool 1.5

[Scott James Remnant]

On Sun, 2004-01-04 at 20:06, Gary V.Vaughan wrote:

> I have no problem with starting to use shell functions to libtool now,
> and infact I think that it is the best way to bring some sanity to the 
> code spaghetti we are trying to maintain.  For now, I don't think it is 
> safe to rely on any more advanced shell function features than 
> enumerated parameter passing.
> 
Here's what Blinn has to say:

/bin/sh on older shells, including (at least) ULTRIX don't support them,
do we drop support for those platforms?

Some shells also would overwrite libtool's own $1...$# once the first
function is called, so we should be sure to capture all shell script
arguments before calling any function lest they be lost.

On ULTRIX and HP-UX there's a /bin/sh5 which supports functions and
positional parameter stacking.

> Here's a function (plus a bit of supporting gubbins) excerpted from 
> libtoolize:
> 
> : ${MKDIR="mkdir"}
> 
> sed_dirname='s,/[^/]*$,,'
> 
> # func_mkdir_p dir
> # Make sure the entire path to DIR is available.
> func_mkdir_p ()
> {
>      my_dir=$1
>      my_dirs=
> 
>      while test ! -d "$my_dir"; do
>        my_dirs="$my_dir $my_dirs"
>        case $my_dir in */*) ;; *) break ;; esac
>        my_dir=`echo "$my_dir" | sed "$sed_dirname"`
>      done
>     test ! -n "$my_dirs" || $MKDIR $my_dirs
> }
> 
Looks sane, though the only instance of "mkdir -p" in libtool was that
one, and that only creates one subdirectory under ${TMPDIR-/tmp}, which
probably should exist beforehand anyway.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

signature.asc
Description: This is a digitally signed message part