On Sun, Feb 18, 2018 at 12:36:43PM +0100, Klemens Nanni wrote:
> On Tue, Nov 21, 2017 at 08:30:25PM +0100, Klemens Nanni wrote:
> > On Sun, Nov 12, 2017 at 10:43:46PM +0100, Klemens Nanni wrote:
> > > On Sun, Nov 12, 2017 at 09:04:22PM +0000, Robert Peichaer wrote:
> > > > Hmm. I see.
> > > >
> > > > The {add,del,no,pre}_path functions are in ksh.kshrc since when it was
> > > > imported 21 years ago. If they would be used in ksh.kshrc or anywhere
> > > > else, I'd say it might be worth "fixing" these functions. But they are
> > > > not used anywhere in the tree and I would rather remove them
> > > > alltogether.
> > > >
> > > > In case someone uses them, ~/.kshrc seems to be a more appropriate
> > > > place.
> > > I personally prefer keeping them but won't object if the broader consent
> > > is to remove them.
> > >
> > > This makes me wonder who else actually uses those (on a regular basis).
> > Bumping this a week later.
> >
> > Do we fix this (using my earlier diff) or abandon them all together?
> > Here's the latter one as convenient diff.
> >
> > diff --git a/etc/ksh.kshrc b/etc/ksh.kshrc
> > index 5b5bd040f79..923fdc37541 100644
> > --- a/etc/ksh.kshrc
> > +++ b/etc/ksh.kshrc
> > @@ -119,26 +119,3 @@ case "$-" in
> > *) # non-interactive
> > ;;
> > esac
> > -# commands for both interactive and non-interactive shells
> > -
> > -# is $1 missing from $2 (or PATH) ?
> > -function no_path {
> > - eval _v="\$${2:-PATH}"
> > - case :$_v: in
> > - *:$1:*) return 1;; # no we have it
> > - esac
> > - return 0
> > -}
> > -# if $1 exists and is not in path, append it
> > -function add_path {
> > - [[ -d ${1:-.} ]] && no_path $* && eval ${2:-PATH}="\$${2:-PATH}:$1"
> > -}
> > -# if $1 exists and is not in path, prepend it
> > -function pre_path {
> > - [[ -d ${1:-.} ]] && no_path $* && eval ${2:-PATH}="$1:\$${2:-PATH}"
> > -}
> > -# if $1 is in path, remove it
> > -function del_path {
> > - no_path $* || eval ${2:-PATH}=$(eval echo :'$'${2:-PATH}: |
> > - sed -e "s;:$1:;:;g" -e "s;^:;;" -e "s;:\$;;")
> > -}
> >
> We still have the broken _path() functions around and I prefer to simply
> remove them by now.
>
> OK?
IF nobody else speaks up, I'm for removal as stated in a previous email.
