Remove files or directories

`rm' removes each given FILE. By default, it does not remove directories. Synopsis:

rm [OPTION]... [FILE]...

If the `-I' or `--interactive=once' option is given, and there are more than three files or the `-r', `-R', or `--recursive' are given,  then `rm' prompts the user for whether to proceed with the entire operation. If the response is not affirmative, the entire command is aborted.

Otherwise, if a file is unwritable, standard input is a terminal, and the `-f' or `--force' option is not given, or the `-i' or `--interactive=always' option _is_ given, `rm' prompts the user for whether to remove the file. If the response is not affirmative, the file is skipped. Any attempt to remove a file whose last file name component is `.' or `..' is rejected without any prompting. _Warning_: If you use `rm' to remove a file, it is usually possible to recover the contents of that file. If you want more assurance that the contents are truly unrecoverable, consider using `shred'.

The program accepts the following options. Also see *note Common options::.

`-f'
`--force'

Ignore nonexistent files and never prompt the user. Ignore any previous `--interactive' (`-i') option.

`-i'
Prompt whether to remove each file. If the response is not affirmative, the file is skipped. Ignore any previous `--force'  (`-f') option. Equivalent to `--interactive=always'.

`-I'
Prompt once whether to proceed with the command, if more than three files are named or if a recursive removal is requested. Ignore any previous `--force' (`-f') option. Equivalent to `--interactive=once'.

`--interactive [=WHEN]'
Specify when to issue an interactive prompt. WHEN may be omitted, or one of:
* never - Do not prompt at all.
* once - Prompt once if more than three files are named or if a
* always - Prompt for every file being removed. Equivalent to
`-i'.
`--interactive' with no WHEN is equivalent to `--interactive=always'.
`--one-file-system'

When removing a hierarchy recursively, skip any directory that is on a file system different from that of the corresponding command line argument. This option is useful when removing a build "chroot" hierarchy,
which normally contains no valuable data. However, it is not uncommon to bind-mount `/home' into such a hierarchy, to make it easier to use one's start-up file. The catch is that it's easy to forget to unmount `/home'. Then, when you use `rm -rf' to remove your normally throw-away chroot, that command will remove
everything under `/home', too. Use the `--one-file-system' option, and it will warn about and skip directories on other file systems. Of course, this will not save your `/home' if it and your chroot happen to be on the same file system.

`--preserve-root'
Fail upon any attempt to remove the root directory, `/', when used with the `--recursive' option. This is the default behavior. *Note Treating / specially::.
`--no-preserve-root'
Do not treat `/' specially when removing recursively. This option is not recommended unless you really want to remove all the files on your computer. *Note Treating / specially::.

`-r'
`-R'
`--recursive'
Remove the listed directories and their contents recursively.

`-v'
`--verbose'
Print the name of each file before removing it.


One common question is how to remove files whose names begin with a `-'. GNU `rm', like every program that uses the `getopt' function to parse its arguments, lets you use the `--' option to indicate that all following arguments are non-options. To remove a file called `-f' in the current directory, you could type either:

rm -- -f

or:

rm ./-f

The Unix `rm' program's use of a single `-' for this purpose predates the development of the getopt standard syntax.  An exit status of zero indicates success, and a nonzero value indicates failure.

Explicitly Specifying Welcome Pages

A welcome page refers to the page that appears when you specify a URL that is a directory. On UNIX systems, an example is /usr/local/ In web applications, this translates to http://localhost:8080/, http://localhost:8080/restricted/ and on and on and on. The servlet specification states that the server should first locate the index.jsp page. If unavailable, then the index.html page. Now the servlet specification does not specify what the servlet/ web container should do if the index.jsp and/ or the index.html pages are unavailable. The next action of the server is therefore server specific. Some servlet containers simply throw an HTTP 404 error, others list the contents of that directory. Such divergent behaviour of servlet containers from the various vendors may make your application behave differently on different containers (much like the behaviour of programs running on different platforms such as UNIX and Windows without any code changes that were developed using other programming languages such as C). This definitely makes your web application much less portable. The purpose of specifying the welcome pages in the web.xml file is to ensure uniform behaviour of your web application across all these different containers keeping the promise of the Java programming language and platform of Write Once and Run Anywhere (WORA). There are ways in which such diverse behaviour of the web servers can be overcome. One way is to explicitly create the index.jsp file in that directory or the index.html page or both. The other way is to specify the welcome page using the welcome tags of the web.xml file. The first approach is self explanatory. We will discuss the second approach instead. In order to specify the resource that should be returned when a visitor of your site or user of your web app, you should consider the <welcome-file-list> tag of the web.xml file. This tag has an opening and closing tag. Do not forget the closing tag How this works is like so; 1: <welcome-file-list> 2: <welcome-file>firstPage.jsp</welcome-file> 3: <welcome-file>secondPage.html</welcome-file> 4: <welcome-file>thirdPage.jsp</welcome-file> 5: </welcome-file-list> The servlet container will be obliged to display firstPage.jsp first; if firstPage.jsp suddenly becomes unavailable for some sinister reason, then secondPage.html will be displayed instead. If secondPage conspires to go AWOL as well, the server loads up thirdPage.jsp. This helps in making issues explicit and not having to rely on server specific behaviour which in some cases may not be merciful. Consider the situation where the index.jsp and index.html files are unavailable and the server displays the contents of the directory as if it were on ftp. Also the server throwing a HTTP 404 Error. Such behaviour is definitely unacceptable.