Re: Problem with 'rm -i' in ksh

On 11.01.2025 16:16, Kenny McCormack wrote:

In article <slrnvo4udu.a76.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber  <naddy@mips.inka.de> wrote:

On 2025-01-11, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>

  rm -i "${!a_set[@]}"
=>
rm: remove regular file `rmd2'? rm: remove regular file `rmd4'? rm:
remove regular file `rmd9 2'? rm: remove regular file `rmd9 3'?

>
Well, that's what you get when you redirect stdin to null:
>
$ rm -i *
remove a? n
remove b? n
remove c? n
$ rm -i * </dev/null
remove a? remove b? remove c? $

 
Yeah, that was my first reaction as well.  But it seems so obvious, that it
seems unlikely that this particular poster would have fallen into that trap.

Sometimes it may be necessary to refresh an old man's brain. ;-)
But you are right, I'd have noticed such suspicious redirections.

 
Maybe the script is being executed in some non-normal environment, say in
cron, or in an "init" script, where stdin is redirected to /dev/null.

Yeah, something that I also thought about. - But in this case it's
just a normally run script (tested in ~/bin through PATH search and
with explicit ksh interpreter). - Here I thought more about any fancy
changes in ~/.profile or ~/.kshrc that might have affected behavior.
But yet I haven't spotted anything apparent; environments get overly
complex, though.

 
A couple of other comments:
 
1) I've found out recently that, under certain, as yet undetermined,
conditions, scripts run from .profile have stdin == /dev/null.

Well, I'd not really expect interactive input in .profile, but if it's
not specified that is or would be bad.

2) I think that "rm" should (*) open up /dev/tty to prompt for yes/no,
rather than rely on standard input.  It should fail/exit with an error
message if /dev/tty can't be opened (which will happen if the process has
no controlling terminal).

Indeed. - But thinking about that... - using stdin might be considered
advantageous if one wants to connect a controlling tool (say, an AI -
LOL) to judge/control the command. Quite unlikely its usefulness, but
that's the one thing that occurred to me for such a design.

Janis

 
(*) "should" in the sense of does not now, but the world would be better if
it did.