6

The third party scheduling application our enterprise uses doesn't execute rm commands as expected. By this, I mean I expect the rm -f $filetoremove to complete and then continue to the next line of code in the script.

But I need to get it to execute preferrably rm -f.

Is there another method to remove a file without using rm? I tried > delete_foobar.file but it just empties it without removing.

Additional information: My work environment is a large enterpise. I write the .sh script which I test outside the scheduling application. Outside the scheduling software, the rm -f $filetoremove command works with a return code of 0. However, the scheduling software does not register the 0 return code and immediately exits without running the remainder of the .sh script. This is problematic and the vendor has acknowledged this defect.

I'm not privy to the details of the automation software nor the exact return codes it receives. All I know, is that my scripts don't run completely, when run via the automation software, if it contains rm. This is why I'm looking for alternatives to rm.

Yes, it is important that I remove the file once I've completed processing it.

closed as unclear what you're asking by Kusalananda, steve, l0b0, icarus, muru Feb 5 '17 at 14:23

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    What happens when you rm? – Kusalananda Feb 5 '17 at 7:48
  • 2
    Please let us know what "as expected" means. We don't know if you're on a system without rm or if simple has a malformed $PATH environment variable. – Kusalananda Feb 5 '17 at 8:19
  • Is removing the content of the file enough? (the file itself will be kept) – Eng7 Feb 5 '17 at 8:37
  • rm, after executing, returns a non zero return code to the application, or the application mis-reads the return code of 0 as something else In either case, the application then proceeds to exit without excuting the remainder of the script. The vendor has acknowledged this as a defect. – zundarz Feb 5 '17 at 8:39
  • 1
    @zundarz: You can get a more useful answer if you provide more info, e.g. the command-line arguments the application runs rm with, the error message of rm, the value of $PATH when the application runs rm. Most probably rm is working just fine on your system (and there is no better alternative), but the application invokes it incorrectly. – pts Feb 5 '17 at 10:21
13

The unlink command is also part of POSIX:

unlink <file>
8

Are you able to run shred? If so, then:

shred -u <file to remove>
7

Is there another method to remove a file without using rm?

busybox rm -f path/to/file

This is assuming your scheduling application allows you to run busybox unrestricted. Since you haven't specified which application it is, we don't really know what the restrictions are, but the above should work if the application has a simple molly guard preventing execution of just rm.

6

With a GNU find, find /your/file -delete could work.

1

Move the file to /tmp:

mv filename /tmp

and it will be deleted at the next reboot.

  • Next reboot may be years away. Last time I rebooted my Linux laptop was a couple of month ago. Last time I rebooted my Linux server was... never? – Aleks G Feb 5 '17 at 11:19
  • 5
    @AleksG Did you just tell us you didn't do security updates for a very long time? – Max Ried Feb 5 '17 at 12:15
  • @MaxRied No. I do them all the time - there's never been a need to restart the machine though. They are all applied inline with corresponding modules unloaded/reloaded and services restarted. But the actual machine does not need restarting. – Aleks G Feb 5 '17 at 13:09
  • @MaxRied It's not windows, remember? – Aleks G Feb 5 '17 at 13:13
  • @AleksG the actual machine does not need restarting. What about the parts of the kernel that aren't modules? So yes it does need reboots, unless you want to remain on your old base kernel version and not fix any security issues in that part of the kernel. So you're probably still vulnerable to issues such as CVE-2016-9754 and likely a host of other security issues. – Andrew Henle Feb 5 '17 at 13:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.