Re: [bug #46007] texi2dvi Msys support

[Gavin Smith]

On 25 September 2015 at 18:19, Vincent Belaïche
<address@hidden> wrote:
> If there were some bash extension to restrict in some way the syntax of
> some envvars or of some commands, then MSYS would have that missing
> information which is needed to do all the conversion properly.
>
> These declarations would be helpful not only for the MSYS case, but in
> general for any *nixy platform they would allow if need be to activate
> some strict mode where the envvar settings/command launching could be
> error controlled for syntax by bash. Making a project portable accross
> platforms *nix/MSW would then just consist in declaring at some point
> this syntax information, there would not be any need to modify and make
> hard to read/understand scripts, no need in texi2dvi to replace in many
> places some of the `:' by $path_sep and set path_sep in the correct way
> by detecting through a number of tricks what the underlying platform is,
> you would just declare the envvar/commands syntax at some point (your
> init file or the script itself) and the rest would be done for you by
> the bash port. So, in the end there would be far less impact on scripts
> like texi2dvi to get the compatibility.

(Not Texinfo related: please ignore if you're not interested.)

Maybe the shell could have a hook for a user-defined wrapper that
could be used to implement arbitrary changes to the environment?

I'm trying to think how such a thing could work. The first idea is to
allow specifying a program that would be called for every command the
shell launches. It would inherit environment variables and could
change them. But how would the command go on to be launched? One way
would be for the command to be passed the command-line, but ideally
anyone writing such a wrapper wouldn't have to process shell syntax.
At a minimum it would to pass on the argv and argc arguments to the
main function.

I understand when a shell launches a process, it forks (creating a
copy of the shell process), sets up the environment for the process
(for example environment variables and file descriptors), and then
uses the "exec" call to replace itself with the program being
launched. What would be interesting would be if there was a way to
intervene after the fork, but before the exec.

An obvious language for such a hook would be shell script itself. If
you launched a separate program written in language like C or Perl,
you would have to rely on it knowing how to launch the program being
launched, because there's no way to pass environment variables back to
the parent process, but shell commands could be executed directly in
the forked shell process, affecting its state.

What about changing a command's command-line arguments, or not calling
it at all? Maybe setting the values of the arguments like $1, $2, etc.
could change the arguments that the process will get.