Bugzilla Bug 190143

I request to execute all files in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d in
alphabetical order from the scripts /etc/ppp/ip-up and /etc/ppp/ip-down,
respectively (of course, passing all environment variables and arguments).

This would allow third party ebuilds (e.g., I was just writing an ebuild for
SuSE's accounting tool from smpppd) to add required scripts (or even programs)
during opening/closing the net connection without touching existing scripts.

Moreover, if the current three functionalities of the /etc/ppp/ip-{up,down}
scripts would be put into the files
/etc/ppp/ip-{up,down}/40-mangle-resolv.conf
/etc/ppp/ip-{up,down}/50-net.x-init
/etc/ppp/ip-{up,down}/99-run-local
   (the latter might be a symbolic link to /etc/ppp/ip-{up,down}.local)
the user could execute something before/between/after this functionality, while
currently only the latter is possible with /etc/ppp/ip-{up,down}.local

This change is important, so I will ask for comments on dev ml. 

Fixed in the pmasked revision ppp-2.4.4-r12. 
I don't have a test environment right now so I need you to test it for me. Once
I have you confirmation that it works as it should, I'll remove the pmask.

Thanks. On my machine it works smoothly.

However, I am wondering whether it wouldn't be better to use
   ./"${SCRIPT}" "$@"
instead of
   source ./"${SCRIPT}" "$@"
(BTW: IIRC there are some shells which only understand the "." keyword instead
of the "source" keyword).
Of course, if you change from "source" to normal execution, you should also
chmod +x 90-local after moving to make sure that the user's files are executed
even if the user had relied on "source" (and also 40-dns 50-initd would have to
be executable, of course).

Reasons against "source"/".": It might happen that variable settings (or even
worse: things like set -e) of the scripts interfere with each other
unintentionally.
Moreover, since you changed from #!/bin/bash to #!/bin/sh, the user might still
want the possibility to change back to #!/bin/bash for certain scripts if he
has to rely on bash features: This is not so easily possible when "source"/"."
is used.

The only reason in favour of "source"/"." which I found is that the
corresponding partition might be mounted with noexec option; however,
ip-up/ip-down cannot be on such a partition anyway.

BTW: If you do not like moving the user's ip-{up,down}.local, another solution
might be to still source it in addition (IIRC this is what SuSE does). However,
the change from #!/bin/bash to #!/bin/sh might cause troubles for the user's
ip-{up,down}.local in any case (although I welcome this change).

(In reply to comment #3)
> (BTW: IIRC there are some shells which only understand the "." keyword instead
> of the "source" keyword).

I tried those scripts with busybox and they worked, so I reckon "source" is not
bash-ism.

> Reasons against "source"/".": It might happen that variable settings (or even
> worse: things like set -e) of the scripts interfere with each other
> unintentionally.

On the other hand, using source will prevent the initial process to fork for
every script you have in ip-*.d directory. 

> Moreover, since you changed from #!/bin/bash to #!/bin/sh, the user might still
> want the possibility to change back to #!/bin/bash for certain scripts if he
> has to rely on bash features: This is not so easily possible when "source"/"."
> is used.

If their /bin/sh is a symlink to /bin/bash, I don't see why they would need to
change it.

> BTW: If you do not like moving the user's ip-{up,down}.local, another solution
> might be to still source it in addition (IIRC this is what SuSE does). However,
> the change from #!/bin/bash to #!/bin/sh might cause troubles for the user's
> ip-{up,down}.local in any case (although I welcome this change).

I'm perfectly okay with that. In the previous version ip-up script "sourced"
the local script, therefore previous scripts are bash ones.
I will ask for other opinions on IRC. You might try to expose your suggestions
on ml, although I didn't saw much interest on the matter.

I really like that idea.

for SCRIPT in * ; do
        source ./"${SCRIPT}" "$@"
done

But some critics: Using source when using /bin/sh is really bad. I use dash on
one system - and it does NOT support source.
$ source /tmp/x
dash: source: not found

And please make that loop ignore backup files like editors create them. (*.bak
*~ maybe).

Most other such loops had fixed file-name endings (hotplug using *.dev) or just
*.sh.

Nevertheless the change to /bin/sh will not cause trouble. Only for people
switching /bin/sh symlink to anything else - and still using bashisms in their
local scriptlets.

I consider the bug as fixed.
Again, thank you very much.

Anyway, some final comments:

> I tried those scripts with busybox and they worked,
> so I reckon "source" is not bash-ism.

"source" is not POSIX compatible but dot (".") is, see
http://www.opengroup.org/onlinepubs/009695399/idx/sbi.html
see also e.g. the ChangeLog of keychain 1.3.

> On the other hand, using source will prevent the initial process to fork for
> every script you have in ip-*.d directory.

I had thought that the time difference is not so large, since the shell is in
memory anyway, but some tests showed it is actually enormously.
To prevent scripts from interfering with each other unintentionally, you might
still think about using a subshell
  ( . ./"${SCRIPT}" "$@" )
which is for some reason still much faster than execution, even in bash.
But on the other hand, it is slower than without a subshell anyway, and the
user should know what he is doing if he adds scripts...

> If their /bin/sh is a symlink to /bin/bash, I don't see why they would need
> to change it.

Even if /bin/sh is a symlink to /bin/bash, the bash enters POSIX compatibility
mode which has slightly different behavior as if /bin/bash is run directly.
Moreover, there are some reasons (speed or compatibility testing) to change the
/bin/sh symlink to another shell, so the user might have done it and relied on
the previous #!/bin/bash for ip-{up,down}.local anyway. Perhaps an ewarn is
appropriate.

Fixed in -r13 as follows:
 - add ipv6-{up,down} symlinks to ip-{up,down} scripts. This should make pppd
work seamlessly for IPv6 links
 - use . instead source
 - avoid using echo -e (another portability problem)
 - force .sh suffix on ip-{up,down}.d scripts (/bin/sh scripts are the only one
supported by this scheme)

bash's "POSIX compatibility" mode when invoked as /bin/sh is pretty lenient ...
it continues to support pretty much all bashisms, so for all intents and
purposes, there would be no functional difference