Tag Info

New answers tagged

7

How about (cd lib && echo *.jar), assuming that you don't have whitespace or special characters in the file names. Parent script never changes directory.


-1

An alternative way solve your query is to list all the files using ls -R. Combine the output of ls command with grep to list only .jar files. You can use following command to do the same for your query: ls -R lib | grep jar| grep -v jar*


5

With GNU find there is no need to run basename for every single file, this will be much faster (especially if there is a lot of files): find lib -name '*.jar' -printf '%P\n'


0

find is probably the way to go, but if you really, really do (you don't) want to strip off lib/ from ls -1, you can use sed: $ ls -1 lib/*.jar | sed 's#^lib/##' mylib_1.jar mylib_2.jar


6

As Josh Jolly said in his answer, you should never parse ls, use the approach in his answer instead. Still, here's an awk solution to remove paths from file names, just don't use it with ls: find . | awk -F'/' '{print $NF}' The -F'/' sets the field separator to / which means that the last field, $NF, will be the file name.


14

Instead of parsing ls you should use find instead. Then you can also execute basename on each file to strip the leading directories: find lib/ -name '*.jar' -exec basename {} \;


7

This is simply done with an alias; alias ls="ls -1" You can put this in your .bashrc file, although it probably already contains the following alias to give colourised output: alias ls="ls --color=auto" In which case you would just add to it giving: alias ls="ls --color=auto -1"


1

find doesn't have sophisticated options like ls. If you want ls -h, you need to call ls. find / -maxdepth 10 -size +100000 -exec ls -lh {} + I recommend the -xdev option to avoid recursing into other filesystems, which would be useless if you're concerned about disk space. find / -xdev -maxdepth 10 -size +100000 -exec ls -lh {} + If you use zsh as your ...


1

I think what you are after is more like the following. find / -maxdepth 10 -size +100000 -exec ls -lah {} + The -exec allows you to execute a command and the {} is substituted with the result of the the find. Lastly the + is to tell find it is the end of the command and it is required.


2

The command you are trying is readable to me. However, you can make use of the file utility with the find as below. find / -maxdepth 10 -size +100000 -exec sh -c 'file -b {} | grep text &>/dev/null' \; -print Another way to do this is using the below command. du -BM / | sort -nr The above command will give you the files in the sorted file ...


1

Well, after looking at the source, I had to go all the way. :) There is currently no way of coloring hardlinked executables differently than non-hardlinked executables, other than creating a custom version of ls. Here's how I did it on Ubuntu 10.04.4 (The problem also exists on Ubuntu 13.10, but I wasn't on that when I did it. Should be very similar ...


0

On OS X 10.8, this seems to be ls -lO now (with a capital O). The output from man ls: -O Include the file flags in a long (-l) output. -o List in long format, but omit the group id.


11

This works also with stat: DIR=/ stat -c '%i' $DIR From man stat: -c --format=FORMAT use the specified FORMAT instead of the default; output a new‐ line after each use of FORMAT [...] The valid format sequences for files: %i inode number


11

Yes, the argument -i will print the inode number of each file or directory the ls command is listing. As you want to print the inode number of a directory, I would suggest using the argument -d to only list directories. For just printing the inode number of your home directory, use the following command line: ls -id ~ From man ls: -d, --directory ...


2

If you are having trouble understanding endianess, here's another illustration. #include <stdio.h> #include <inttypes.h> #include <unistd.h> int main (void) { uint16_t x = 1; write(1, &x, 2); x = 2; write(1, &x, 2); return 0; } This is C code which will write out 2 16-bit values, 1 and 2. When we think ...


1

hexdump -x displays the values as if they were 2-byte integers. On a little-endian machine this will display each pair of bytes in swapped order, treating them as two-byte quantities with the high-order (second) byte first, followed by the low-order (first) byte. As you've seen, using hexdump -C displays the actual bytes. The actual contents of your ...


4

As others have pointed out, this is because hexdump -x treats the files as containing 2-byte words. On little endian systems (almost all desktops are), this means the bytes will be swapped before they are displayed. This means that the byte values are printed in pairs and that the order of these bytes are swapped. Since you have an odd number of bytes, ...


2

Sounds like you have some directory that matches CD*. When you run ls -l CD* you're seeing the contents of this directory, which includes the file CDTEST. Example Say I had this directory structure. $ tree . . `-- CD1 `-- CDTEST 1 directory, 1 file If I run the following command from the same location: $ ls -l CD* total 0 -rw-rw-r--. 1 saml saml 0 ...


0

From what I understand, the CDTEST file appears to be inside a folder. When you issue the command, ls -l CD* The above command actually displays a file CDTEST inside your folder which is not present in the present working directory. So, if you do ls -l it would not display the CDTEST file which is inside the folder. And that is the reason a new file is ...


8

On GNU systems at least in most locales other than C/POSIX, there are a few characters that are ignored with regards to sorting. That's the case for instance of _, ., space or 0x1. That's why .a, .c, __b, _d sort as .a, __b, .c, _d for instance. For strings that consist only of those ignored characters, the sort order is defined in the locale, ASCII SPC ...


9

^, in ASCII order, follows the uppercase letters. - precedes all the letters and digits, but follows several other punctuation characters. The ASCII printable characters, in order, are: !"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ `abcdefghijklmnopqrstuvwxyz{|}~ But this doesn't necessarily help you, since the order in ...


2

The difference is simple: with ampersand (&) execution of your program is sent to background and while it is happening, you can execute other commands. As ls command takes only short time to run, you don't really notice it. It could be easier illustrated with sleep command and bash script. In example I set it to sleep (wait) for 5 seconds. This also ...


3

Running in the background still means the output goes to the terminal by default. The difference is that you type other commands while the program is running. Obviously this will be difficult with programs like ls that produce a lot of output. Try this: ls -alR / >ls_files & You will be able to do other things while ls is running. The first time ...


4

Because the object of the ls invocation is not the same. In the first case, the argument is the current directory (.), and the link is displayed only incidentally (because the argument is a directory and the link is in it). In the second case, it is among the explicitly listed arguments, and the special rule "follow symbolic links" applies only to the ...



Top 50 recent answers are included