Hi Lawrence,

On Sat, Oct 04, 2025 at 11:13:51AM -0400, Lawrence Velázquez wrote:
> Sure it does.  Redirections can be infixed, so these are all valid:
> 
> 	<file cmd arg

my prefered one by far

> 	cmd arg <file

The one i kept using for years just because examples use it while isn't
now my most hated by far. a good demonstration about reading the man
pages even if you think you know the tool.

> 	cmd <file arg

> Someone who agrees with your argument should logically expect this
> to "work":
> 
> 	set file arg
> 	cmd < "$@"

I have to admit I forgot this one because I considered it confusing and
useless but thanks to your example, I realize today is a convenient way to
place the data source in "$1" instead of the top of stack and that could
be useful in dash scripting because where is no simple/rubust way to get
this top (the equivalent of $argv[-1] in zsh). But as "$@" in not
expanded after <, this usecase is wasted as well.

fool() {
	local source="$1"
	echo "content of $source:"
	cat < "$@"
}
fool mind -n

content of mind:
sh: 4: cannot open mind -n: No such file

> >> Almost no shell works the way you are expecting, except for zsh in
> >> native mode (which I suspect is where you first tried this syntax)
> > Not at all.
> Ah, well.  I guessed so because I know from the zsh mailing lists
> that you're a big zsh fan.

I'm also fan of rc and long time user of mksh, I also used tcsh at the end
of the last millenium and tested any other ones (including exotic ones
like zoidberg and elvish).

I once (~ 10 years ago?) wrote an email to Tom Duff to thank him for rc
ask him why there was no advanced variable expansions in rc (like
${foo#bar}, ${foo?oops} and so on). He answered me that nobody were using
them back then. He also wrote something that has a deep impact of the way
I think about shell scripting:

	«rc means "run commands" and should not do much more»

from this day, I started to bet on external commands much more than
shell internals and realized my scripts where faster and more reliable.

As I didn't need all the zsh features anyore (and rc is sadly too
unknown to be used when you want to share your scripts), dash became my
almost only shebang (also almost all my scripts are working in a bare
busybox chroot, including CGIs).

I keep using zsh for interactive stuff because there is no competitor
on this part of the game thanks to

* "alternate syntax" for control statements
* advanced features like extended globs, list filtering, filename modifiers
* incredible zle widgets

> > As the behavior is undefined, of course, I would like to propose to
> > behave the most helpful way when it makes sense because
> >
> > * the other usecases are already doable:
> > 	* if the expected behavior is "$*", so use "$*"
> > 	* what's the point of A  < "$@" ? use "$1" instead
> > * it's a matter of consistency to me. why "$@" can't behave as "$@" ?
> 
> One could easily make the same "consistency" argument from the
> perspective of the redirection operator.  POSIX disallows this
> expansion from producing multiple fields...
> 
> 	var='foo bar'
> 	cmd < $var
> 
> ...so why should this one produce multiple fields?
> 	set foo bar
> 	cmd < "$@"

from the POSIX perspective, it indeed shouldn't.

> In any case, the existing behavior conforms to POSIX and is far
> more portable, so it is not likely to change.

That's what I learnt from you (again: thank you so much) and
made me so sad: consistency on POSIX compliance avoid consistency around
useful behaviors. On the other hand, I totally support the idea that at
least one shell must be POSIX compatible flaw by flaw.

there is no perfect shell in this world :)

regards

-- 
Marc Chantreux
Pôle CESAR (Calcul et services avancés à la recherche)
Université de Strasbourg
14 rue René Descartes,
BP 80010, 67084 STRASBOURG CEDEX
03.68.85.60.79