rm command in pbs_postinstall results in unexpanded wildcards in filename if used in sudo.

<p>To address comment, I tried running INSTALL under sudo as follows on vcc@testdev-02-s11p2:~/PBSPro_13.0.2&gt;&nbsp;<br />
sudo PATH=/opt/tools/wrappers:$PATH ./INSTALL and I was unable to reproduce this issue and INSTALL worked fine.</p>

I also tried to run:<br>&nbsp; rm -f /etc/rc.d/rc?.d/*pbs<br><br>under sudo with /opt/tools/wrappers in the start of PATH and did not see the problem:<br><br>vcc@testdev-02-s11p2:_{&gt; ls -l /etc/rc.d/rc?.d/*pbs <br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc3.d/K01pbs -&gt; ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc3.d/S08pbs -&gt; ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc5.d/K01pbs -&gt; ../pbs<br>lrwxrwxrwx 1 root root 6 Oct 29 21:32 /etc/rc.d/rc5.d/S08pbs -&gt; ../pbs<br><br>vcc@testdev-02-s11p2:}&gt; PATH=/opt/tools/wrappers:$PATH rm -f /etc/rc.d/rc?.d/*pbs<br>/bin/rm: cannot remove `/etc/rc.d/rc3.d/K01pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc3.d/S08pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc5.d/K01pbs': Permission denied<br>/bin/rm: cannot remove `/etc/rc.d/rc5.d/S08pbs': Permission denied<br><br>vcc@testdev-02-s11p2:_{&gt; sudo PATH=/opt/tools/wrappers:$PATH rm -f /etc/rc.d/rc?.d/*pbs<br>&nbsp;<br>vcc@testdev-02-s11p2:}&gt; ls -l /etc/rc.d/rc?.d/*pbs <br>ls: cannot access /etc/rc.d/rc?.d/*pbs: No such file or directory<br>[Security:Internal]

<p>The wrappers are getting passed what is essentially garbage. The installer should not do this.<br />
With few exceptions, e.g. find's -name option which takes escaped wildcards and uses glob itself<br />
when ftw executed, the shell almost always does any wildcard expansion – it's not up to the called program to<br />
do this. So, I think the vast majority of prior art indicates the wrappers are behaving in the<br />
least surprising ( i.e. the correct ) way.</p>

<p>At present, the wrappers have a rule that silently ignores this condition, but in the case of<br />
something like rm, this means that some files may be left behind which should not be.</p>

<p>Could you explain why this is a bug with PBS post install vs. the wrappers?</p>

<p>More from Harry's email:&lt;br&gt;&lt;br&gt;&lt;font size='2'&gt;&lt;span style='font-size:10pt;'&gt;As to what's wrong, that's simple. The shell script is passing unexpanded wildcards to the<br />
&nbsp;<br />
wrapped functions. E.g. instead of&nbsp;<br />
&nbsp;<br />
rm file1 file2 file3</p>

<p>the wrapped rm is seeing&nbsp;<br />
&nbsp;<br />
rm file*&lt;br&gt;<br />
&nbsp;<br />
It's the shell's job to expand the list before calling the wrapper.&nbsp;<br />
&nbsp;<br />
I found a case that I thought would explain it. This involved the euid not being able to<br />
read the directory contents. However, the installer runs as root, so although it's<br />
an interesting case, it isn't really relevant. I don't know why the installer is doing<br />
what it does, but I do think I've shown that it's wrong in my previous email<br />
since these scripts often use the -f flag with rm, in the past it was just<br />
failing silently anyway since a file with a wildcard in the name didn't exist.<br />
What the wrappers have revealed is that whatever the author of the script had intended to<br />
happen, probably isn't.</p>