I have three files, one a real ("regular") file and two chained symlinks:
-rw-r--r-- 1 user staff 24 4 Nov 18:23 A
lrwxr-xr-x 1 user staff 1 25 Oct 17:43 B -> A
lrwxr-xr-x 1 user staff 1 4 Nov 16:54 C -> B
Now, using zsh conditional expressions ([[), I test whether B (or C) is a regular file or a symlink, and zsh says yes to both ...:
18:31 : [[ -f B ]] && echo "True"
True
18:31 : [[ -h B ]] && echo "True"
True
Isn't a symlink supposed not to be a regular file? zsh documentation of conditional expressions (here) doesn't give full details on how different cases work.
zsh --version
zsh 5.0.5 (x86_64-apple-darwin14.0)
edit
After more digging, I found this Q&A on Unix.SE : https://unix.stackexchange.com/questions/22009/distinguishing-a-regular-file-from-a-symlink. It's about bash but it looks like it also applies to zsh.
zsh is almost certainly using the S_ISREG() and S_ISLNK() macros from lstat(2). Since S_ISLNK() is younger than S_ISREG(), I imagine symlinks were historically treated like regular files here (since they aren't directories, block/character devices, etc.), and the behavior was kept for backwards compatibility. I wasn't able to find any direct evidence of this, however.
Related
I bumped into the fact that MacOS GNU bash5.1.16 "ls" command doesn't differentiate between lower and upper case in the files names ( weird, I know)
e.g.
[17:39:28:~/Work/cloud-formation/output/templates$] ls -l Man*
-rw-r--r-- 1 geoku staff 71244 31 Jan 17:23 ManagementProd.json
-rw-r--r-- 1 geoku staff 67569 31 Jan 17:23 ManagementStage.json
Now, I can get the exactly same file listed with a different command:
[17:44:19:~/Work/cloud-formation/output/templates$] cksum ManagementStage.json Managementstage.JsOn
cksum ManagementStage.json Managementstage.JsOn
3327010753 67569 ManagementStage.json
3327010753 67569 Managementstage.JsOn
Is it some sort of bash settings?
OK, it turns out MacOS disk partitions can be created case-sensitive or not, and default is apparently the second one
Disk utility shows the options when one is trying to create a new partition
enter image description here
I'm checking an alternative to 'find' command in shell scripting so as to eliminate the discrepancy of Accessed date of sub directories.
According to my observation, when find command is executed to list all the files in a directory, the accessed date of sub-directories is getting changed.
I want to post genuine statistics in one of the junk platforms, So I have been looking at some forums and got the alternative with 'ls' command. But that doesn't completely fulfill my request.
Below is the answer given by #ghostdog74.
ls -R %path% | awk '/:$/&&f{s=$0;f=0} /:$/&&!f{sub(/:$/,"");s=$0;f=1;next} NF&&f{ print s"/"$0 }'.
But this finds only the files inside the sub directories. I need all the files and sub-directories' files to be listed.
For example:
bash-3.2# pwd
/Users/manojkapalavai/Desktop/SleepTimeReport
bash-3.2# ls
**6th floor** manoj17 manoj26.txt manoj36 manoj45.txt manoj55 manoj70.txt manoj80 manoj9.txt **test1**
manoj14 manoj23.txt manoj33 manoj42.txt manoj52 manoj61.txt manoj71 manoj80.txt manoj90 **test2**.
The highlighted ones are sub-directories inside "SleepTimeReport" directory and remaining are just files. So, when I execute the above command, I get only the below output.
bash-3.2# ls -R ~/Desktop/SleepTimeReport | awk '/:$/&&f{s=$0;f=0} /:$/&&!f{sub(/:$/,"");s=$0;f=1;next} NF&&f{ print s"/"$0 }'.
~/Desktop/SleepTimeReport/6th floor/Script to increase the Sleep Time.numbers.
~/Desktop/SleepTimeReport/6th floor/Zone1Sleep.pages.
~/Desktop/SleepTimeReport/test1/New_folder.
~/Desktop/SleepTimeReport/test1/manoj.txt.
~/Desktop/SleepTimeReport/test1/sathish.txt.
~/Desktop/SleepTimeReport/test1/vara.txt.
~/Desktop/SleepTimeReport/test1/New_folder/Script to increase the Sleep Time.numbers.
~/Desktop/SleepTimeReport/test1/New_folder/Zone1Sleep.pages.
i.e.; only those files inside sub-directories are listed.
Brief explanation of what issue I'm facing, please see below
Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ ls -l
total 16
drwxr-xr-x 8 manojkapalavai staff 272 Sep 14 15:07 6th floor
-rwxr-xr-x 1 manojkapalavai staff 59 Nov 13 10:41 AltrFind.sh
-rw-r--r-- 1 manojkapalavai staff 0 Nov 2 15:15 manoj%.txt
-rw-r--r-- 1 manojkapalavai staff 0 Nov 2 18:23 manoj1
When I try finding Created time and Accessed Time of the folder 6th floor before using 'find' command, the below is output.
Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ stat -f '%N, %SB, %Sa' 6th\ floor/
6th floor/, Sep 13 10:34:55 2017, **Nov 13 11:21:33 2017**
Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ find /Users/manojkapalavai/Desktop/SleepTimeReport/
/Users/manojkapalavai/Desktop/SleepTimeReport/
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/.DS_Store
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/Script to increase the Sleep Time.numbers
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/Zone1Sleep.pages
Now, after finding all the files inside a directory, below is the output of atime. you can notice the change
Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ stat -f '%N, %SB, %Sa' 6th\ floor/
6th floor/, Sep 13 10:34:55 2017, **Nov 13 14:26:03 2017**
All tha I have done is just find the files, and atime of sub-folders inside a folder when we find is getting changed to that current time.
Is there any way to solve this?
ls is the wrong tool for programmatic use. Generally, you should be able to fix your find usage to not have an effect on atimes (actually, it's pretty rare for folks to even have atimes enabled at the filesystem level on modern production systems), but if you really want to avoid it, consider the bash globstar option:
shopt -s globstar
for file in **/*; do
echo "Doing whatever with $file"
done
*Edit - Stephen has answered this question in the comments below *
so basically I have made two seperate child processes(using two seperate methods with their own fork) to execute the command ls -la | less using pipe.
The first one executes ls like this:
execl("/bin/ls", "ls", "-la", NULL);
The second child process executes less like this:
execlp("less", "less", NULL);
And the results come up fine.. apart from one little part:
Results using shell command:
total 15
drwxr-xr-x 2 daniel staff 4 2015-02-27 18:58 .
drwxr-xr-x 15 daniel staff 24 2015-02-27 18:58 ..
-rwxr-xr-x 1 daniel staff 9280 2015-02-27 18:58 pipes
-rw-r--r-- 1 daniel staff 1419 2015-02-27 18:58 pipes.c
Results using my executable:
total 30
drwxr-xr-x 2 daniel staff 4 Feb 27 18:58 .
drwxr-xr-x 15 daniel staff 24 Feb 27 18:58 ..
-rwxr-xr-x 1 daniel staff 9280 Feb 27 18:58 pipes
-rw-r--r-- 1 daniel staff 1419 Feb 27 18:58 pipes.c
Now the date being a different format I don't care about.. but the total size is twice as large with my executable(30 vs 15). Why is this happening?
Make sure that the ls you are running from the shell and the ls that is running in your program are the same program.
Your program is specifying /bin/ls as the program to run; you can find out what is being run when you type the command at the shell prompt by using the shell command which ls (also see type ls).
If these are different it could be due to the POSIX vs. GNU blocksize used in the total size computation.
This answer indicates that POSIX and GNU tools differ in the blocksize they use to compute the total. Try adding h to your command and compare the results (this flag makes the units explicit). My guess is that the execution environment of these processes is disturbing the result. For instance it may not be the same ls that you are running.
Since making a hash of a complete binary file would be far too heavy to compute in a reasonably fast time:
What are sufficient file information for hashing a file? The following lists what properties the resulting hashing should ideally have:
collision-free in respect to other files in the directory
fast
catch all file changes
As a rule of thumb, the less information we can use to create enough entropy, the better. Since the speed of retrieval for specific information may depend largely on the given environment (OS, file-IO of the language, IO of the used library, etc.), it should be disregarded here.
(This is my first attempt at a community wiki. My reason for making it one is that the information asked here is very generic but (hopefully) informative. I also would like this question to be marked as a community wiki, so it can be improved where fit. )
General Overview
Our goal here is to track as much differences between two file states while not using redundant data. Thus each informational source must be a disjointed subset of the information of the files state.
The following items represent sources of information about a file:
the name of the file
the directory-path relative to the specified document-root (aka absolute from document-root)
the files permissions
the files owner (user/group)
the last change time
the size of the file
the hostname of the machine the file resides on
the actual saved binary data
Per Item Considerations
Name of File
The name of the file is part of its absolute filesystem's path (the last bit) and as #La-comadreja said, it is unique in that no two files on a system can have the same absolute path. Using the File's name in combination with the rest of its absolute path (see directory-path for more information) is highly encouraged to avoid hash collisions with other files.
Directory-Path
While the files absolute path will be perfectly unique, it should be noted that in certain circumstances hashing the absolute path may be inappropriate. For instance, comparing the hashes of two files on different machines will most likely fail when both files do not have the identical absolute path on both machines. This becomes even more problematic on machines with different OS's and/or architectures. It is therefore encouraged to specify a document-root and resolve an absolute path from there.
Permissions
If you want to track changes to a files permissions, the tests below indicate that you would need to incoporate them into your hash directly as they do not change any other information about the file (most notably the timestamp). Note however that permissions are handled quite differently on different machines, so caution must be exercised here (for instance to use a canonical permission translation scheme).
Ownership
Ownership, just as permissions, is handled very differently across architectures and filesystems. A change of ownership does not change other information (as indicated by the tests below).
timestamp
The timestamp of a file is also something that is not unifiedly implemented across all (or at least the most common) systems. First of all, there are different timestamps on different filesystems we could be looking at: creation date, modified date, access date, etc. For our purpose the modified date is most suitable, as it is supported by most of the available filesystems [1] and holds the exact information we need: the last change to a file. However comparing files across different OS's may pose a problem, as Windows and Unix handle timestamps (in general) differently (see here [2] for a detailed article about the problem). Note that the modification date of a file changes whenever a file has been edited (disregarding edge cases), so timestamp indicates changes in file size (note that the opposite does not hold true, see file-size).
File size
The file size in bytes is an extremely good indication whether a file has been edited (except for permissions, ownership and name changes), as each edit would change the files content, thus changing its size. However this does not hold true if additions to a file are exactly as big as deletions. Thus the files timestamp may be a better indicator. Also, calculating a files binary size may be quite computation intensive.
Hostname
If one wants to compare files across multiple hosts and regard identical files on different hosts as different, then the hostname of the machine (or another suitable unique identifier for the host) should be included in the hash.
Binary Data
The binary data of the file has, of course, all necessary information to check if a file was changed. However, it is also too resource intensive to be of any practicability. It i highly discouraged to use this information.
Suggestions
The following sources should be used to compare files:
the name of the file
the directory path
the timestamp (see above for problems)
The following extra sources can be used to track more information:
permissions (see above)
ownership (see above)
hostname (when comparing across different machines)
The following sources of information should be disregarded:
file size
binary data
Tests
I did some tests on Debian checking whether changing one information would change another. Most interestingly rename, permission change, owner change did not affect a timestamp change or filesize change. (Note that these tests are currently only tested on Debian Linux. Other OS's will likely behave differently.)
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ mv baz baz2
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ chmod 777 foo
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ mv baz2 baz
$ echo "Another string" >> bar
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ sudo chown root baz
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 root alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
Assuming all the files are on the same machine, directory path and file name should produce a unique combination because two files in the same directory cannot have the same name. Directory path, filename and timestamp of last change should capture each change.
If the files are on different machines, the machine name should be included in the directory path.
In terminal, I want to make a bunch of folders appear in a certain order. It isn't alphabetical, but in an unrelated order. When I do this:
mkdir this folder is going to be
The folders all show up correctly in Finder, but alphabetized. I have confirmed that the folder's view options are set to Sort By: None, Arrange By: None.
Is there a different way to accomplish this?
If you really want "no order" you will get unpredictable results. Seems like you want file creation date or file modification date (oldest first) order.
This command:
$mkdir this folder is going to be
is misleading, because you have no idea what algorithm 'mkdir' is using internally to create the folders (unless you read the source), so no idea what order is actually going to result, from the point of view of the filesystem (its not the order you expect).
To be clearer, you need to issue the command once per file
$ mkdir this
$ mkdir folder
$ mkdir is
$ mkdir going
$ mkdir to
$ mkdir be
then you can list in reverse modified-date order:
$ ls -tr
this folder is going to be
$ ls -ltr
total 0
drwxr-xr-x 2 user staff 68 6 Jan 20:41 this
drwxr-xr-x 2 user staff 68 6 Jan 20:41 folder
drwxr-xr-x 2 user staff 68 6 Jan 20:41 is
drwxr-xr-x 2 user staff 68 6 Jan 20:41 going
drwxr-xr-x 2 user staff 68 6 Jan 20:41 to
drwxr-xr-x 2 user staff 68 6 Jan 20:41 be
on the native mac filesystem hfs+ there is also a 'creation date' flag, which is probably what you want, but this is not very portable across other filesystems.
IN the finder, arrange by > date created
or arrange by > none, view in list view, with 'date created' column showing, and click on it.
You can't; folders are inherently not ordered.