Hey Johan,
> Ok, so IINM, Anders' original commit was about making "git submodule
> foreach <command>" behave more like "<command>" (from a naive user's
> perspective),
Ok, that makes sense.
> while you rather expect to insert quotes/escapes to finely control
> exactly when shell interpretation happens.
Well, I mostly expect that the $name and $path that git submodule makes
available to each command invocation can actually be used by the
command.
> Aren't these POVs mutually incompatible? Is the only 'real' solution
> to forbid multitple arguments, and force everybody to quote the entire
> command?
Yes, I think you're right that they're mutually exclusive. Specifically,
if you expect git submodule foreach <command> to behave like <command>,
that means you expect the (interactive) shell to do all the
interpolation, word-splitting, etc. If so, you can't then later still do
interpolation (of course, you could do sed magic to just replace $name
and $path, etc., but that's broken).
> I don't particularly care which way it goes, as long as (a) the common
> case behaves as most users would expect, (b) the uncommon/complicated
> case is still _possible_ (though not necessarily simple), and (c) we
> don't break a sizable number of existing users.
Well, if you call submodule directly, you can now just put everything in
a single command and get $name interpolation.
As I mentioned, I couldn't do this because I was using a git alias.
However, a bit of fiddling showed a solution to that using a shell
function:
[alias]
each = "!f(){ git submodule foreach --quiet \"echo \\$name $*\";}; f"
This uses a shell function to collect all alias arguments and then uses
$* to expand them again into the single submodule foreach argument. Note
that $* is expanded when evaluating the alias, while \\$name is expanded
later inside submodule.
This suggests that with the current code, the more complicated cases are
still possible. There is one catch in this approach, in that the
original word splitting is not preserved ($* expands to just the
unquoted arguments as a single word). I'm not sure if this is fixable
($@ expands to multiple quoted words, but then foreach sees multiple
arguments and doesn't do the eval). One would need to escape the output
of $@ somehow (e.g., add \ before ", but that would become terribly
complicated I expect...).
Perhaps an explicit --eval switch to git submodule makes sense for
complete control? If it has a correspondning --no-eval, you can even
pass a single-argument command without evalling, while still keeping the
current "least surprise" approach as the default?
Whatever behaviour is settled for, it should be documented in the
submodule manpage (which I think is not the case now).
Gr.
Matthijs
Attachment:
signature.asc
Description: Digital signature