File expressions in bash

There is quite a lot to say about testing and one of the most common tasks is checking files on the filesystem or if a directory is available or has some rights. So, imagine a script that has to write some data in a file inside a directory: first, we should check whether the directory exists, then if we can write into it, and finally if there is no name collision between the file we are going to open for writing and an already existing file. So let's have a look at which operators we use to execute some tests on files and devices and remember that they return true if the condition is met:

-e: Returns true if a file exists:

 ls test-files.sh 
test-files.sh

We just verified that the file test-files.sh exists since ls shows it:

 if [ -e test-files.sh ] ; then 
echo "Yes, this is a file!" ; fi
Yes, this is a file device!

Our test confirms it with a nice message.

Let's verify now that a file named aaaaa is not present in our current directory:

 lsaaaaa
ls: cannot access 'aaaaa': No such file or directory

OK, there is no file with such a name; let us do a test:

 if [ -e aaaaa ] ; then echo "Yes, this is a file!"; 
else 
echo "There is not such a file!" ; fi
There is not such a file!

Well, as you can see, we used a semicolon to divide the different parts of the statement. In a script, we would have seen the following:

#!/bin/bash
if [ -e aaaaa ]
then
echo "Yes, this is a file!"
else
echo "There is not such a file!"
fi

Each single command must be properly terminated either by a new line or a ;. Each chunk of code delimited by a ; will be executed before the following without the need for a new line.

-a: This has the same purpose of -e, but it is deprecated.
-b: This checks whether the file is actually a block device, like a disk, a CD-ROM, or a tape device:

 if [ -b /dev/nvme0n1p1 ] ; 
then 
echo "Yes, this is a block device!" ; fi
Yes, this is a block device!

-d: This checks whether a file is actually a directory or not:

 if [ -d test ] ; 
then echo "Yes, this is a directory!" ; 
else echo "There is not such a directory!" ; fi
Yes, this is a directory!

-f: This checks whether a file is a regular file and does not represent something like a character device or a directory or a block device:

 if [ -f /dev/tty7 ] ; 
then echo "Yes, this is a regular file!" ; 
else echo "There is not a regular file!" ; fi
There is not a regular file!

Well, this is a file that represents a terminal, so it is clearly not a regular file as test.file could be:

 touch test.file    
 if [ -f test.file ] ; 
then echo "Yes, this is a regular file!" ; 
else echo "There is not a regular file!" ; fi
Yes, this is a regular file!

-c: This tests if the argument is a character file:

 if [ -c /dev/tty7 ] ; 
then echo "Yes, this is a character file!" ; 
else echo "There is not a character file!" ; fi
Yes, this is a character file!

-s: This is true if the file is not of 0 size:

 if [ -s test.file ] ; 
then echo "Yes, the size of this file is not 0!" ; 
else echo "The size of this file is 0!" ; fi
The size of this file is 0!

Well, we just touched the file, so we created it with 0 byte size. Let's fill it with a character:

 echo 1 >>test.file

And now, let's repeat the test:

 if [ -s test.file ] ; 
then echo "Yes, the size of this file is not 0!" ; 
else echo "The size of this file is 0!" ; fi
Yes, the size of this file is not 0!

-g: This is true if the directory has a sgid flag set. As we saw, the set group ID imposed on a directory forces the files newly created into it to be owned by the group who owns the directory itself:

 if [ -g test ] ; 
then echo "Yes, this dir has a sgid bit" ; 
else echo "No sgid bit on this dir" ; fi
No sgid bit on this dir

And now:

 chmodg+s test
 if [ -g test ] ; 
then echo "Yes, this dir has a sgid bit" ; 
else echo "No sgid bit on this dir" ; fi
Yes, this dir has a sgid bit

-G: This is true if the group ID is the same as that of yours. Let's test on a file first:

 if [ -G test.file ] ; 
then echo "Yes, this file has your same group owner" ; 
else echo "No the group owner is not the same of yours" ; fi
Yes, this file has your same group owner

And now on a directory:

 if [ -G test ] ; 
then echo "Yes, this file has your same group owner" ; 
else echo "No the group owner is not the same of yours" ; fi
Yes, this file has your same group owner

Let's double-check changing the group owner of test.file:

 su
Password: 
root:# chgrp root test.file
root:# ls -lahtest.file
-rw-r--r-- 1 zarrelli root 2 Feb  6 18:23 test.file
root:# exit
exit
 if [ -G test.file ] ; 
then echo "Yes, this file has your same group owner" ; 
else echo "No the group owner is not the same of yours" ; fi
No the group owner is not the same of yours

-O: This is true if you are the owner:

if [ -O test.file ] ; 
then echo "Yes, you are the owner" ; 
else echo "No you are not the owner" ; fi
Yes, you are the owner
 ls -lahtest.file
-rw-r--r-- 1 zarrellizarrelli 2 Feb  6 18:23 test.file

-N: This is true if the file was modified since the last read. This can become handy when you want to backup a file or just see if new information has been added. A typical scenario would be a log file or a data file being fed by a process, a service: if in a certain amount of time, the file has not been modified it probably means that the process is not running or not working properly so we can probably do something like restart it. So, let's have a look at one of our previous scripts:

 if [ -N userinput-or.sh ] ; 
then echo "Yes, it has been modified since last read" ; 
else echo "No modifications since last read " ; fi
No modifications since last read

OK, the files seems to have not been modified lately, so it is time to modify it:

 echo 1 >> userinput-or.sh 
 if [ -N userinput-or.sh ] ; 
then echo "Yes, it has been modified since last read" ; 
else echo "No modifications since last read " ; fi
Yes, it has been modified since last read

That's it. Remember that in all the tests when we say that the test is true when the condition is verified, we imply a second condition that is the file must exist. So in this case, we would say, it is verified if the file exists and has not been modified from last read. Also remember that in Unix everything is a file, so a directory.

-u: This is true if the suid bit is flagged. This kind of test can become quite useful for different reasons related to the fact that when you run an executable it usually runs with the privileges of the user who invoked it. With the suid bit flagged the executable is run with the privileges of the owner of that executable file not with the ones of the invoker also not with those of the one who invoked it. So, a program owned by root with the suid bit flagged can be a real harm to the security of a system since whoever invokes it has the root rights over the system itself. On the other side of the medal some programs, especially those that must have root rights to access a device, need to have the suid bit flagged because this allows a normal user to access the devices as root without having to access the full root environment:

zarrelli:$ su
Password: 
root:# chown root test.file
root:# ls -lahtest.file
-rw-r--r-- 1 root zarrelli 2 Feb  6 18:23 test.file
root:# chmod +s test.file
root:# ls -lahtest.file
-rwSr-Sr-- 1 root zarrelli 2 Feb  6 18:23 test.file
root:# exit
exit
 if [ -u test.file ] ; 
then echo "Yes, it has the suid bit flagged" ; 
else echo "No suid bit found" ; fi

-k: This is true if the sticky bit is flagged. This kind of privilege is really interesting because if imposed on a file, it will have the file held in memory resulting in faster access, but applied to a directory it restricts the user rights: only the directory owner of the owner of the file inside a directory with a sticky bit set will be able to delete the file itself. This comes really handy in a collaborative environment where several users have their working file in the same directory, and applying the sticky bit on it will give the file owners the right to delete their files only:

 chmod +t test
 if [ -k test ] ; 
then echo "Yes, it has the sticky bit set" ; 
else echo "No sticky bit set" ; fi
Yes, it has the sticky bit set

-r: This is true if the read permission is set for the user executing the test:

 if [ -r test.file ] ; 
then echo "Yes, this user can read the file" ; 
else echo "No this user cannot read the file" ; fi
Yes, this user can read the file

So, the user can read the file, let's check the following:

ls -lahtest.file
-rwSr-Sr-- 1 root zarrelli 2 Feb  6 18:23 test.file

Oh, well, the file is owned by root and root has read access, so why was the test successful if the read is granted to root? Simple:

 su
Password: 
root:# chmodog-r test.file
root:# exit
exit
 if [ -r test.file ] ; 
then echo "Yes, this user can read the file" ; 
else echo "No this user cannot read the file" ; fi
No this user cannot read the file

What happened? The first time we tried the test the owner was root, but the user zarrelli was still able to read the file through group permission and other permission. So, clearing those bits made the file readable only by the root user, no one else.

-w: This is true if the write bit is set:

 if [ -w test.file ] ; 
then echo "Yes, this user can write to the file" ; 
else echo "No this user cannot write to the file" ; fi
No this user cannot write to the file

Interesting, let's have a look at the file:

 ls -lahtest.file
-rw---S--- 1 root zarrelli 2 Feb  6 18:23 test.file

Indeed, only the root user can write to it. Would you like to try and fix the issue then run the test again?

-x: This is true if the execution bit is set:

 if [ -x test.file ] ; 
then echo "Yes, this user can execute it" ; 
else echo "No this user cannot execute it" ; fi
No this user cannot execute it

Let's see what the access permissions on the file are:

ls -lah test.file
-rw---S--- 1 root zarrelli 2 Feb  6 18:23 test.file

So no execute bit for the user. Now, let's test a directory:

 if [ -x test ] ; 
then echo "Yes, this user can execute it" ; 
else echo "No this user cannot execute it" ; fi
Yes, this user can execute it

Interesting, time to see the permissions on the directory:

 ls -lah test
total 8.0K
drwxr-sr-t 2 zarrellizarrelli 4.0K Feb  6 18:12 .
drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 08:12 ..

What are those dots and double dots? Let's have a closer look:

ls -lai
total 8
5900830 drwxr-sr-t 2 zarrellizarrelli 4096 Feb  6 18:12 .
5899440 drwxr-xr-x 3 zarrellizarrelli 4096 Feb  7 08:12 ..

Keep in mind the first column. These are the inode numbers related to .. and..:

zarrelli@:~$ cd ..
zarrelli@:~$ ls -lai
total 36
5899440drwxr-xr-x 3 zarrellizarrelli 4096 Feb  7 08:12 .
5899435 drwxr-xr-x 3 zarrellizarrelli 4096 Feb  7 20:47 ..
5900830 drwxr-sr-t 2 zarrellizarrelli 4096 Feb  6 18:12 
test
5899311 -rw---S--- 1 root     zarrelli    2 Feb  6 18:23 
test.file
5899447 -rwxr--r-- 1 zarrellizarrelli  319 Feb  5 11:42 
test-files-not.sh
5899450 -rwxr--r-- 1 zarrellizarrelli  317 Feb  5 11:21 
test-files.sh
5898796 -rw-r--r-- 1 zarrellizarrelli    0 Feb  7 08:00 
test.modified
5899448 -rwxrwxr-x 1 zarrellizarrelli  352 Feb  5 12:31 
userinput-and.sh
5899449 -rwxr-xr-x 1 zarrellizarrelli  190 Feb  5 12:41 
userinput-and-simple.sh
5899444 -rwxrwxr-x 1 zarrellizarrelli  305 Feb  7 08:07 
userinput-or.sh

The inode of . inside the test directory has the value of 5900830, so now we go up one directory, and we can see that the test directory has an inode value of 5900830. So, we can safely say that .points to the directory we are in. And what about ..? Look at the value of .in the parent directory, it is 5899440. Now look inside the test directory to the value of .., it is 5899440, and so we can safely say that..points to the parent directory since both point to the same inode.

Briefly, to understand what relates an inode to a file, we can say that in a Unix style file system, an inode is a metadata structure describing file and directories attributes, such as type timestamp, size, access rights, links count, and pointers to the disk block holding the data that make up a file or directory content. Each inode number is practically an index that allows the kernel to access a file or directory, its content and attributes, such as an index in an array. And actually, you can know quite a bit of a file if you know how to look at it:

 stat test
  File: test
  Size: 4096      Blocks: 8          IO Block: 4096   
  directory
Device: fd01h/25025aInode: 5900830     Links: 2
Access: (3755/drwxr-sr-t)  Uid: ( 1200/zarrelli)   Gid: ( 1200/zarrelli)
Access: 2017-02-06 18:12:53.376827639 +0000
Modify: 2017-02-06 18:12:53.376827639 +0000
Change: 2017-02-07 19:26:15.936253432 +0000
 Birth: -

So, what we can say is that something pointing to the same inode number is pointing to the same data structure, the same file or directory, and that is what links the .. and .to the representation of the parent and local directory as we proved by following the inode numbers.

-h -L: This is true if a file is a link. A link is a pointer to another file and you can have either a soft or hard link:
- A soft link is a reference to a file that can span across different filesystems. It is a special kind of file holding a reference to another file, so when the operating system tries to access the link, it recognizes it as a link and redirects all the operations to the actual file pointed by it. If the target is removed the link remains, but points to nothing. The main limits of a soft link is that it creates an overhead in the operations; the OS must redirect all the operations from it to the target.
- A hard link is another file pointing to the same inode and because inodes are a metastructure of a file system, a hard link cannot span across filesystems. Once the original file is deleted, the hard link is not affected since it points to a valid inode, which actually remains on the file system even if the file is deleted. A limit is that it cannot point to a directory.

So, to make it easy, we can say that the soft link is a pointer by name to a file, whereas a hard link is a pointer by inode. Let's see some differences in play starting with a soft link:

 ln -s test.filenew.test.file
zarrelli@:~$ ls -lah | grep new
lrwxrwxrwx 1 zarrellizarrelli    9 Feb  7 21:48 new.test.file ->test.file

Let's cat the link:

 su
Password: 
root:# chmoda+rtest.file
root:# exit
exit
 cat new.test.file
1

Now, let's remove the original file:

 rmtest.file

And verify if we can access the content through the link:

 cat new.test.file
cat: new.test.file: No such file or directory

The problem is clear with ls:

 ls -lah
total 32K
drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 22:06 .
drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 22:02 ..
lrwxrwxrwx 1 zarrellizarrelli    9 Feb  7 21:48 
new.test.file ->test.file
drwxr-sr-t 2 zarrellizarrelli 4.0K Feb  6 18:12 
test
-rwxr--r-- 1 zarrellizarrelli  319 Feb  5 11:42 
test-files-not.sh
-rwxr--r-- 1 zarrellizarrelli  317 Feb  5 11:21 
test-files.sh
-rw-r--r-- 1 zarrellizarrelli    0 Feb  7 08:00 
test.modified
-rwxrwxr-x 1 zarrellizarrelli  352 Feb  5 12:31 
userinput-and.sh
-rwxr-xr-x 1 zarrellizarrelli  190 Feb  5 12:41 
userinput-and-simple.sh
-rwxrwxr-x 1 zarrellizarrelli  305 Feb  7 08:07 
userinput-or.sh

The link is still there, but the original file is gone, so when the OS tries to reach it, it fails. Let us recreate the original file and the link:

 rmnew.test.file
 rmnew.test.file
 echo 1 >test.file
 ln -s test.filenew.test.file

Now, let's link across the /boot filesystem. First, let's check that /boot is mounted on its own partition and filesystem:

 mount  | grep boot
/dev/nvme0n1p1 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl)

OK, it is really another filesystem, so let's soft link:

 su
Password:     
root:# ln -s test.file /boot/boot.test.file

And access the link:

root:# cat /boot/boot.test.file
cat: /boot/boot.test.file: No such file or directory

Well, something has gone wild. What is happening? Have a look with ls -lah:

root:# ls -lah /boot/boot.test.file
lrwxrwxrwx 1 root root 9 Feb  7 22:19 /boot/boot.test.file 
->test.file

Well, the link points to test.file in /boot even though we linked from another directory. We need an absolute reference:

root:# ln -s /home/zarrelli/test.file /boot/new.test.file
root:# cat /boot/new.test.file

And now it works. Finally, let's see what happens if we try to link a directory:

 ln -s test new.test

We linked new.test to the test directory and now just check that the test directory is empty:

 ls -lah test
total 8.0K
drwxr-sr-t 2 zarrellizarrelli 4.0K Feb  7 22:29 .
drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 22:26 ..

Now, let's create a file using the link:

 echo 2 >new.test/testing
 cat test/testing 
2

And let's see what is in test:

 cat test/testing 
2

Here we are; we can reach the data inside test using the new.test soft link.

Now it is time to hard link across filesystems:

 su
Password: 
root:# ln  /home/zarrelli/test.file /boot/hard.test.file
ln: failed to create hard link '/boot/hard.test.file' =>'/home/zarrelli/test.file': Invalid cross-device link

No way! We cannot reference with a hard link across filesystems; the inode restriction is preventing us from doing it.

Now, let's try to link a directory:

 ln test hard.test
ln: test: hard link not allowed for directory

Again, no good to go. Now, let us try to hard link in the same filesystem:

 lntest.filehard.test.file

No problem, but let's have a look at the inodes:

 ls -lai
total 40
5899440 drwxr-xr-x 3 zarrellizarrelli 4096 Feb  7 22:35 .
5899435 drwxr-xr-x 3 zarrellizarrelli 4096 Feb  7 22:33 ..
5899465 -rw-r--r-- 2 zarrellizarrelli    2 Feb  7 22:11 
hard.test.file
5899355 lrwxrwxrwx 1 zarrellizarrelli    4 Feb  7 22:26 
new.test -> test
5900839 lrwxrwxrwx 1 zarrellizarrelli    9 Feb  7 22:12 
new.test.file ->test.file
5900830 drwxr-sr-t 2 zarrellizarrelli 4096 Feb  7 22:31 
test
5899465 -rw-r--r-- 2 zarrellizarrelli    2 Feb  7 22:11 
test.file
5899447 -rwxr--r-- 1 zarrellizarrelli  319 Feb  5 11:42 
test-files-not.sh
5899450 -rwxr--r-- 1 zarrellizarrelli  317 Feb  5 11:21 
test-files.sh
5898796 -rw-r--r-- 1 zarrellizarrelli    0 Feb  7 08:00 
test.modified
5899448 -rwxrwxr-x 1 zarrellizarrelli  352 Feb  5 12:31 
userinput-and.sh
5899449 -rwxr-xr-x 1 zarrellizarrelli  190 Feb  5 12:41 
userinput-and-simple.sh
5899444 -rwxrwxr-x 1 zarrellizarrelli  305 Feb  7 08:07 
userinput-or.sh

The hard link points to the same inode of the original file, the soft link does not. Now remove the original file again and try to cat the hard and soft link:

 rmtest.file
 cat new.test.file
cat: new.test.file: No such file or directory
 cat hard.test.file
1

As we expected, the soft link failed because there is no filename to point to, the hard link succeeded because the inode is still there:

ls -lahi
total 36K
5899440 drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 22:40 .
5899435 drwxr-xr-x 3 zarrellizarrelli 4.0K Feb  7 22:33 ..
5899465 -rw-r--r-- 1 zarrellizarrelli    2 Feb  7 22:11 
hard.test.file
5899355 lrwxrwxrwx 1 zarrellizarrelli    4 Feb  7 22:26 
new.test -> test
5900839 lrwxrwxrwx 1 zarrellizarrelli    9 Feb  7 22:12 
new.test.file ->test.file
5900830 drwxr-sr-t 2 zarrellizarrelli 4.0K Feb  7 22:31 
test
5899447 -rwxr--r-- 1 zarrellizarrelli  319 Feb  5 11:42 
test-files-not.sh
5899450 -rwxr--r-- 1 zarrellizarrelli  317 Feb  5 11:21 
test-files.sh
5898796 -rw-r--r-- 1 zarrellizarrelli    0 Feb  7 08:00 
test.modified
5899448 -rwxrwxr-x 1 zarrellizarrelli  352 Feb  5 12:31 
userinput-and.sh
5899449 -rwxr-xr-x 1 zarrellizarrelli  190 Feb  5 12:41 
userinput-and-simple.sh
5899444 -rwxrwxr-x 1 zarrellizarrelli  305 Feb  7 08:07 
userinput-or.sh

A quick rule of thumb is do not use soft link to reference frequently accessed files, such as web pages, use them for config files for instance, as they are just read at the startup. Soft links are slow. Hard links are good for referencing files and preserve their content despite what happens to the origin:

-p: This is true if the file is a pipe. Recall for a while what we said in the first chapter about pipes and named pipes; they are a way to get different processes to communicate between each other. If a process is spawned by a parent is not a big deal, they share the same environment and the same file descriptors, on the open descriptor of the parent process, the child will be able to read data in the same order it was written with a buffer kernel to host the bits waiting to be read. For processes that do not share a common environment we can use a pipe that leverages a file that the processes can cling to: this file can last longer than the processes that make use of it, usually until a reboot and can be deleted or redirected. These kinds of interprocess communication structures are called named pipes or First In First Out (FIFO) pipes, based on the order of the data processed. Let us make an example and create a pipe, either with mkfifo or mknode:

 mkfifomyfifo

Now, let's open a second terminal and issue, in the same directory, the command:

 cat myfifo

The process will hang waiting for something to read. Now, let's go back to the first terminal and write something to the named pipe:

 echo hello >myfifo

Now back to the second terminal to check what happened:

 cat myfifo
hello

We will see more on named pipes in one of the next chapters, now we will just check if myfifo is really a named pipe:

 if [ -p myfifo ] ; 
then echo "Yes, it is a named pipe" ; 
else echo "No it is not a pipe" ; fi
Yes, it is a named pipe

-S: This is true if it is a socket. As we already saw, a socket is an endpoint between two devices on the same system or across the network and it allows the devices to exchange data, quite as we saw for pipes and named pipes. As you can easily guess, a Linux system has quite a bunch of sockets:

     if [ -S /tmp/OSL_PIPE_1000_SingleOfficeIPC_39e ] ; then echo "Yes, it is a named pipe" ; else echo "No it is not a pipe" ; fi
Yes, it is a named pipe

And we can double-check looking for and in the property of the file as listed by ls:

 ls -lah /tmp/OSL_PIPE_1000_SingleOfficeIPC_39e 
srwxr-xr-x 1 zarrellizarrelli 0 Feb 12 09:02 /tmp/OSL_PIPE_1000_SingleOfficeIPC_39e

We can see an s character at the beginning of the permissions list, and this is what tells has that this file is exactly a socket, as we expected.

-t: This is true if a file is linked to a terminal. A classic use for this test, as you will find almost in all guides, is to check if a stdin or a stderr in a script is linked to a terminal. Let's check what the stdout of our shell:

 if [ -t 1 ] ; 
then echo "Yes, it is associated to a terminal" ; 
else echo "No it is not associated to a terminal" ; fi
Yes, it is associated to a terminal

Need to double-check it? Simple, since the output of our command issued in the current shell has been printed to our monitor, which is connected to the terminal.

file -ntother_file: This is true if the file is newer than other files, comparison made on their modification dates. Let's have a look:

 touch other_file ; 
for i in {1..10}; do : ; done ; touch file; 
if [ file -ntother_file ] ; 
then echo "Yes, file is newer then other_file" ; 
else echo "No file is not newer than other_file" ; fi
Yes, file is newer then other_file

So, what did we do? We simply chained some commands, and since other_file must be the older piece, we started off creating it. Then, we setup a simple "for" loop iterating between 1 and 10 doing nothing, as implied by the double colon, since we had to let some time pass before creating the newer file. Passed 10 iterations we created a new file and compared the two. One thing that appears interesting in this example is the use of:

{1..10}

This is a construct available since Bash newer than 3.0. Let us quickly set up a range writing the starting number and the ending one. From Bash newer than 4.0, we can also define a range with increments, in the form of:

{start..end..step}

Like in the following example:

 touch other_file ; 
for i in {1..120..2}; do if [ $(($i%5)) -eq 0 ] ; 
then echo "Waiting...cycle $i" ; fi ; sleep 1 ; done ; 
touch file; if [ file -ntother_file ] ; 
then echo "Yes, file is newer then other_file" ; 
else echo "No file is not newer than other_file" ; fi
Waiting...cycle 5
Waiting...cycle 15
Waiting...cycle 25
Waiting...cycle 35
Waiting...cycle 45
Waiting...cycle 55
Waiting...cycle 65
Waiting...cycle 75
Waiting...cycle 85
Waiting...cycle 95
Waiting...cycle 105
Waiting...cycle 115
Yes, file is newer then other_file

Well, added few things here: the cycle now goes from 1 to 120 in steps of 2 and prints out a message only if the cycle number can be divided by 5, so we will not clutter the screen. Finally, we wait for one sec at each cycle using the sleep command to ensure that at the end of the cycle we spent 60 seconds before creating the last file and making the comparison.

We can also modify the date of a file using a specific date, even back in the past, using touch with the format -t YYMMDDHHmm:
ls -lahtest.file
-rw-r--r-- 3 zarrellizarrelli 0 Feb 12 14:56 test.file
touch -t 8504251328 test.file
ls -lahtest.file
-rw-r--r-- 3 zarrellizarrelli 0 Apr 25 1985 test.file

file -otother_file: This is true if the file is older than other_file:

zarrelli:~/$ if [ userinput-or.sh -otother_file ] ; 
then echo "Yes, the first file is older than the second" ; 
else echo "No the first file is not older than the second" ; fi

And indeed:

zarrelli:~/$ ls -laht userinput-or.sh other_file
-rw-r--r-- 1 zarrellizarrelli   0 Feb 12 14:16 other_file
-rwxrwxr-x 1 zarrellizarrelli 305 Feb  7 08:07 userinput-or.sh

Now just touch the userinput-or.sh:

 if [ userinput-or.sh -otother_file ] ; 
then echo "Yes, the first file is older than the second" ; 
else echo "No the first file is not older than the second" ; fi
No the first file is not older than the second

file -efother_file: This is true if the file and other files share the same inode number and device. Have you already heard about files with the same inode number and that they cannot be on different devices? Yes, we call them hard links:

rmtest.file
 rmnew.test.file
 touch test.file
lntest.filenew.test.file
lntest.fileother.new.test.file
 if [ new.test.file -efother.new.test.file ] ; 
then echo "Yes, the files share the same inode number and device" ; else echo "No the files do not share the same inode number and device" ; fi
Yes, the files share the same inode number and device

Now let's double-check:

 lls -laihtest.fileother.new.test.fileother
.new.test.file
5900839 -rw-r--r-- 3 zarrellizarrelli 0 Feb 12 14:56 other.new.test.file
5900839 -rw-r--r-- 3 zarrellizarrelli 0 Feb 12 14:56 other.new.test.file
5900839 -rw-r--r-- 3 zarrellizarrelli 0 Feb 12 14:56 
test.file

All three files share the same inode and, since the inode is a metastructure of a file system, a single file system.

We are done with the file comparison, but there is some more that we have to see, for instance how we can test integers since they are quite a common presence in all the script we see around the Internet.

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

NEWS CONTENTS

Old News ;-)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019

File expressions in bash

NEWS CONTENTS

Old News ;-)

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Etc