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.

Improve this question
10
  • 1
    What happens when you rm?
    – Kusalananda ♦
    Commented Feb 5, 2017 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 ♦
    Commented Feb 5, 2017 at 8:19
  • Is removing the content of the file enough? (the file itself will be kept)
    – Eng7
    Commented Feb 5, 2017 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
    Commented Feb 5, 2017 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
    Commented Feb 5, 2017 at 10:21

5 Answers 5

Reset to default
14

The unlink command is also part of POSIX:

unlink <file>
Improve this answer
1
8

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

shred -u <file to remove>
Improve this answer
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.

Improve this answer
6

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

Improve this answer
1

Move the file to /tmp:

mv filename /tmp

and it will be deleted at the next reboot.

Improve this answer
7
  • 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
    Commented Feb 5, 2017 at 11:19
  • 6
    @AleksG Did you just tell us you didn't do security updates for a very long time?
    – bot47
    Commented Feb 5, 2017 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
    Commented Feb 5, 2017 at 13:09
  • @MaxRied It's not windows, remember?
    – Aleks G
    Commented Feb 5, 2017 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
    Commented Feb 5, 2017 at 13:48

Not the answer you're looking for? Browse other questions tagged .