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.

zundarz
  • 331
  • 3
  • 6
  • 10
  • 1
    What happens when you `rm`? – Kusalananda Feb 05 '17 at 07: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 05 '17 at 08:19
  • Is removing the content of the file enough? (the file itself will be kept) – Eng7 Feb 05 '17 at 08: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 05 '17 at 08: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 05 '17 at 10:21
  • If the script is unable to correctly execute `rm` and detect its exit status, then that will likely also be an issue for any of the other ways that people come up with to delete files in the answers to this question. – Kusalananda Feb 05 '17 at 12:22
  • Create a shell script called `die_file_die_bu_wa_ha_ha_ha_ha.sh` or whatever you like containing `#!bash \n rm -f $1 \n exit 0\n`, make sure it's on your path, and use this instead of `rm`. (Obviously, replace the `\n`'s with real newlines in your file). – Bob Jarvis - Слава Україні Feb 05 '17 at 14:44
  • This continues to sound like a defect in the scheduling software, or a misunderstanding of how it works. If `rm` works in your script, then I think you'll need help from the scheduler vendor. – Jeff Schaller Feb 05 '17 at 20:25
  • Correct, this defect appears applicable only to rm when run in the scheduling software. Until they fix this, I'm left with other alternatives to get my scripts working. – zundarz Feb 05 '17 at 20:30
  • Another trick is to erase but do not delete the fil. eg: echo > $filetoremove – kvaps Oct 01 '20 at 12:31

5 Answers5

14

The unlink command is also part of POSIX:

unlink <file>
kmkaplan
  • 614
  • 4
  • 6
8

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

shred -u <file to remove>
Mia yun Ruse
  • 3
  • 2
airhuff
  • 679
  • 6
  • 23
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.

DepressedDaniel
  • 4,169
  • 12
  • 15
6

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

Ulrich Schwarz
  • 15,669
  • 4
  • 47
  • 58
1

Move the file to /tmp:

mv filename /tmp

and it will be deleted at the next reboot.

chandra
  • 493
  • 1
  • 4
  • 12
  • 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 05 '17 at 11:19
  • 6
    @AleksG Did you just tell us you didn't do security updates for a very long time? – bot47 Feb 05 '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 05 '17 at 13:09
  • @MaxRied It's not windows, remember? – Aleks G Feb 05 '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 05 '17 at 13:48
  • *Move the file to /tmp ..and it will be deleted at the next reboot.*? That's not likely to work - most Linux distributions are configured such that `/tmp` contents are preserved across reboots. – Andrew Henle Feb 05 '17 at 13:51
  • @AndrewHenle Base kernel security vulns are the rarest of the breed. Yes, they do occur, but those are analysed on a case by case basis. The CVE-2016-9754 you refer to isn't a big deal for my laptop, as I am the only user, have full root access anyway and don't really care about local privilege escalation vulns. Ditto with my server, where all local users already have full sudo access; the server is hardened as much as possible and exposed serices are run behind chroot with absolutely minimal privileges. – Aleks G Feb 05 '17 at 13:57