Rewriting this bug as the other one, apparently, was too unclear
to be understood.
This gives an example, two in fact.
On 2020/11/03 14:48, Bernhard Voelker wrote:
On 11/3/20 6:29 PM, L A Walsh wrote:
I tried to use 'env' to find perl in my path and wanted to pass
the -T option to perl.
cat >/tmp/taint+print
#!/usr/bin/env perl -T
printf "Hello World\n";
I am unable to get this to run and print out:
"Hello World" \
Instead of expected output, I get:
/usr/bin/env: ‘perl -T’: No such file or directory
So I tried turning off env's arg parsing as we know the linux kernel
does handle this.
#!/usr/bin/env -- perl -T
/usr/bin/env: unrecognized option '-- perl -T'
Try '/usr/bin/env --help' for more information.
I am not able find a syntax that will generate what I want.
1) '--' isn't handled as being the end of 'env' arguments
2) It isn't splitting white-space to to generate separate arguments
but seems to concatenate together as 1 argument.
3) This overrides normal linux kernel behavior. This is a kernel policy
that is overridden by a user-level program.
*>>* If these behaviors were under user control, I don't think it would be a
problem. While some utils/progs like "find" tend to ignore symlinks
unless they are on the command line. Others, like bash, by default,
try to give a logical view by following the symlinks and restoring when
backing out. Both options can have utility. find even has suboptions for
ignoring their use on the cmdline, but expanding them in subtrees.
Bernhard V. Thanks, so it seems 'env' works as expected and
supports the way you need it to run.
---
Hopefully you understand you had it backwards -- in that it doesn't
work as expected (doesn't break arguments in same places as kernel). and does
not support the way I need it to run.
Do to your misunderstanding you closed the original bug -- Hopefully it is
clear explained enough so this note won't also get deleted.
Have a nice day,
Berny
----
Trying -- at least elections are over.
