Tag Info

Hot answers tagged

17

Because it's the right thing to do. Suppose you had a script doing something like: ls $LS_OPTIONS -l "$dir" where it's possible that $LS_OPTIONS already contains -l. It would be counter-intuitive and annoying for this command to produce an error and would require extra logic in the script to avoid it. -l may not be the best example for this, but ...


16

Short answer: Because it's programmed to ignore multiple uses of a flag. Long answer: As you can see in the source code of ls, there is a part with the function getopt_long() and a huge switch case: 1648 int c = getopt_long (argc, argv, 1649 "abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UXZ1", 1650 ...


15

/bin/ls usually sorts the output. I'm not sure if your "efficient" question is just over system calls or the entire work that is done, but /bin/ls -f would probably do the least work. It only returns the filenames in directory order. No sorting, no additional inode lookups to get metadata (as ls -l would do). Also, if your default ls is colorizing, it ...


13

ls -l is definitely more expensive, since it has to query the file system for metadata such as owner, group, permissions, access time, etc. Vanilla /bin/ls only has to look up the names of the entries in the directory being listed. Note that ls may be aliased on your system to something less vanilla than /bin/ls. Run type ls to see if that's the case.


9

ls is not a bash command, but a separate executable that you happen to launch from bash. That said, -l is just a type of Boolean flag, which if present causes ls to use a long-style format for the output. Most programs will simply ignore multiple uses (ls -ll is the same as ls -l -l) of such flags, although there are some exceptions (as an example, if -v ...


8

ls -t on its own will list all files in the current directory with that sorting, without ever needing to list them on the command line at all. If you need the recursion behaviour of find, or to do some other tests on the files, you can have find generate timestamped entries, either through stat or through GNU find's -printf option and sort it. Something ...


7

This output: $ ls -al /usr/lib/*valgrind* drwxr-xr-x 2 root root 4096 Sep 30 00:01 . drwxr-xr-x 24 root root 12288 Sep 30 00:00 .. -rwxr-xr-x 1 root root 1816444 Jun 6 2014 cachegrind-x86-linux indicates that there is a directory named /usr/lib/*valgrind* (most likely just /usr/lib/valgrind) which you're ...


7

ls -F will: Write a ( '/' ) immediately after each pathname that is a directory, an ( '*' ) after each that is executable, a ( '|' ) after each that is a FIFO, and an at-sign ( '@' ) after each that is a symbolic link. GNU ls includes additional signals: ... ‘=’ for sockets, ‘>’ for doors = is also present in the major BSDs (FreeBSD, OpenBSD, ...


5

Shell aliases would be pretty annoying if commands like ls did not allow repeated options. Suppose you had alias ls='ls --color=auto' alias rm='rm -i' Then, if conflicting flags were not allowed, it would be an error to issue commands like ls --color=never or ls --color=auto or rm -i. Therefore, these commands are designed to let later flags override ...


3

You can use find with perl Posixly: $ find ! -name . -prune -print | perl -lne ' $h{$_} = -M; END { print for sort {$h{$a} <=> $h{$b}} keys %h } ' This assume that you don't have newline character in your filename. To handle newline, you can: $ find ! -name . -prune -exec printf "%s\0" {} + | perl -0lne ... or use perl -le then split ...


3

With ls, you can do: ls -c -ltd -- *PRO*.PLI With find: find . ! -name . -prune -type f -name '*PRO*.PLI' (note that find will include hidden files like .xPRO.PLI while the shell glob (*PRO*.PLI) will not by default).


3

Probably not, though this may have surprised the devs as well. Here's a comment from an excerpted GNU's ls.c: # /* Extensions only apply to regular files, apparently. */ Here is a link to the full ls.c source in which you will find the same, though it is not as pretty to read, maybe. It is worth noting though you can get some alternation in color for ...


2

You can use find. List all files: find . ! -name . -prune -type f List all symbolic link: find . ! -name . -prune -type l List all executable: find . ! -name . -prune -type f -perm +111 You can read POSIX find documentation for more advance options.


2

You can use the file test operators documented in man test. For example, to list symbolic links: for i in *;do if [ -L "$i" ] ;then printf -- "%s\n" "$i";fi;done


2

In zsh: print -rl -- *(om) The glob qualifier om sorts files by modification time (reverse chronological order, i.e. newest first, like ls -t). Use Om to get the opposite order (chronological order, like ls -tr). Make this *(Dom) to include dot files. You can of course vary the pattern, for example **/*(Dom) to recurse into subdirectories. If you want to ...


2

Use find which is better suited for your intended purpose: find . -name "mkmf*" It will list all appearances of your pattern including the relative path. For more information look at manual page of find with man find or go to http://www.gnu.org/software/findutils/manual/html_mono/find.html


2

These are backup files that gedit creates by default. You can disable this feature by going to Preferences → Editor and unchecking the line Create a backup copy of files before saving


1

How to write this command This particular task doesn't call for a pipe. In zsh: a=(/dir1/dir2/filename*.txt(Nom[1])) if ((! #a)); then echo >&2 "No file matches /dir1/dir2/filename*.txt" exit 2 fi variable=$a[1] or, to exit the script automatically if the glob doesn't match: set -e a=(/dir1/dir2/filename*.txt(om[1])) variable=$a[1] Other ...


1

Hypothesis: traversing a directory over NFS is speculatively loading more data than you would expect at once. Way too much IO on the server side, causing a single NFS call to take >20s. mount with intr option might allow Ctrl-C to interrupt the in-flight call. Google found a list of NFS calls which includes READDIRPLUS. Basically readdir + then stat for ...


1

I'm going to assume you're using ls --color=auto, which tells ls to use color in 'automatic' mode. 'Automatic' mode tells less to see if STDOUT is a terminal, and if so, use color, otherwise don't use color. When you pipe ls into less, STDOUT is not a terminal, it's connected to STDIN of less, which is a normal pipe. The solution, use ls --color or ls ...


1

A command like ls -d *@ lists files whose name ends with @. The @ character is part of the pattern that the file name must match. When ls -F displays a character after a file name, that character is not part of the file name, it's an extra indication added by ls (that's the point of the -F option). ls doesn't have an option to select which types of files to ...


1

While Michael Homer already wrote what happened, here's why it happened (given your comment on his answer I think you already know, but others coming across this question might not). The command you issued was ls -al /usr/lib/*valgrind* The stars are interpreted by the shell even before ls is executed, by replacing it with a list of filenames matching ...


1

Since you have "Permission denied" on a directory, it is likely that the directory does not have execute permissions. Similarly, to traverse a directory tree to get at a file, you would need execute permissions on each directory in between the root and the file (hence the same error for the other command). Try setting the execute permissions on the ...



Only top voted, non community-wiki answers of a minimum length are eligible