Tag Info

New answers tagged

1

If you want to copy all the .txt files in a directory, use a wildcard pattern: cp direct/direct1/*.txt target This copies all the .txt files that are in the directory direct/direct1 to the directory target (which must already exist). You can pass multiple patterns to copy files from multiple directories: cp direct/direct1/*.txt direct/direct2/*.txt ...


2

You can use find to only select the `.txt files from under some directory: find direct/direct? -name "*.txt" this would print out all the files, so you can check you got what you wanted, and not too much is going to be selected. The *.txt has to be quoted, otherwise the shell will try expand this to .txt files in the current directory. As for the ...


7

The nullglob option (which BTW is a zsh invention, only added years later to bash (2.0)) would not be ideal in a number of cases. And ls is a good example: ls *.txt Or its more correct equivalent: ls -- *.txt With nullglob on would run ls with no argument which is treated as ls -- . (list the current directory) if no files match, which is probably ...


4

[ $i = "*f*" ] splits the file name stored in the variable i into separate words at spaces, interprets each word as a wildcard pattern and expands it if it matches, and then parses the resulting list of words as a condition for [ … ]. To avoid this rigmarole and instead use the file name, put double quotes around the variable expansion. [ "$i" = "*f*" ] ...


1

Is this an exercise in iterations? If not the use of find may be easier search=$(find /path/to/dir -type f -name *f*) echo $search


1

The test ([ is synonym for the "test" builtin) command didn't allow patterns. STRING1 = STRING2 True if the strings are equal. so it compare strings letter by letter and sure there is not file with *f* name in your directory (so with your reverse-matching script echoes yes when names didn't match). Instead of test-buitin or even ...


1

Since you want to show only files that contain f letter in them, you'd need the continue builtin. For example for f in *; do if [[ $f != *f* ]]; then continue; else printf '%s\n' "$f yes"; fi; done In case you want to show all files with their corresponding yes or no you'd do something like: for f in *; do if [[ $f = *f* ]]; then printf '%s\n' "$f yes"; ...


3

"One or more occurrence" means one or more within the same file name, not one or more file names matching. foo?(.in).x matches foo.in.x while foo*(.in).x should also match foo.in.in.x


5

$ shopt -s extglob $ ls abbc abc ac $ echo a*(b)c abbc abc ac $ echo a+(b)c abbc abc $ echo a?(b)c abc ac $ echo a@(b)c abc


2

It doesn't work in 5.2.7 (newer version) either. I'd suggest trying unrar x file\*.rar, note the dot before rar. That goes down a slightly different code path, at least in 5.2.7, and it works in 5.2.7. Why? Well, after a few minutes of looking through unrar's source (take a look at match.cpp if you want to try!), I can comfortably say "because Alexander ...


1

When you enter unrar x file\*rar, the unrar program receives the literal string file*rar. It's probably easier to just enter unrar x file*rar, which will cause your shell to expand the pattern (unrar will receive the list of files that match the pattern). Now, how come unrar x file\*rar doesn't work while e.g. unrar x file\*.rar does? My guess would be that ...


0

ls *@(10|11|12) is what you're looking for. This requires extglob to be enabled using shopt, i.e., shopt -s extglob. In addition, you can append that line to ~/.bashrc to permanently enable it. For more information on why this works, see the official Bash manual page on pattern matching.


3

Try this : ls *{10,11,12} or ls -l *{10,11,12} (cannot show hidden files)


12

[...] matches one character if it's in the specified set. [10-12] means either character 1 or characters from 0 to 1 or character 2 so the same as [102] or [0-2]. [10,11,12] means either 1, 0, ,, 1... So the same as [,0-2]. Here you want: ls -d -- *1[0-2] That is, (non-hidden) filenames that end in 1 followed by any of the 0, 1 or 2 characters. Now ...


5

This should work: ls -d -- *1[0-2] Remember that [] represents a set of characters and in case of numbers it can go from [0-9]


4

An alternative to Eric's good answer: Tcl can do glob expansion expect <<'END_EXPECT' set timeout -1 # use this instead of sleep set files [glob -nocomplain ~/partFiles/*] if {[llength $files]} { spawn scp -C -o CompressionLevel=9 {*}$files abc@10.200.4.15:/export/home/abc/ expect password send ...


4

I think the ~ and * are expanded by the shell, but I bet expect invokes scp directly, bypassing the shell so those don't get expanded. You could try spawning sh -c the scp command. If it's an option, it might also just be easier to share your key with the server though so you don't need expect for this at all. Using the sh technique the command will end ...


0

Have you tried 'man locate'? If you were to examine the manual for the locate tool you will see that using '\' disables globbing and forces a literal pattern match.


1

find . ! -name . -prune -print | grep -c / Should be fairly portable to post-80s systems. That counts all the directory entries except . and .. in the current directory. To count files in subdirectories as well: find .//. ! -name . | grep -c // (that one should be portable even to Unix V6 (1975), since it doesn't need -prune)


1

When you run zsh interactively, it reads your ~/.zshrc (and also the system /etc/zshrc but if your administrator isn't naughty that isn't the culprit). You're likely to set a few options there that modify how zsh expands commands, in particular extended_glob (which should be the default, if zsh didn't choose to be backward compatible with the early 1990s ...


6

Both are wrong with the zsh default option settings. You can easily see what's going on by using echo as the command instead of mv. Interactively, it looks like you have the null_glob option set. According to the zsh documentation that option is not set by default. What happens with that option unset depends on whether another option, nomatch, is set or ...


9

Not yet. With the extglob option, bash adds some of ksh extended globbing operators but not the {x,y}(pattern) one. In ksh93, you use: {5}(?) With zsh with the extendedglob option: ?(#c5) (you'll notice none of them are shorter than ????? though). In bash, you could do: $(printf '%.0s?' {1..5}) though that's hardly an improvement and relies on ...


0

-C is not a portable option anyway. It's a GNU option not a Unix one. tar is no longer specified by the Single Unix Specification anyway as there's so much difference between the implementations. It has pax to create archives portably. You could do: pax -ws'|.*//||' /backupmnt/statusService//. /some/other/dir//./*.ext | xz > file.tar.xz (xz/gzip ...


2

Why do not use explicit directory change? cd /backupmnt/statusService && tar -czf /backupmnt/abc.tar.gz * Or you can use relative paths: cd / tar -czf /backupmnt/abc.tar.gz backupmnt/statusService1/* backupmnt/statusService2/* backupmnt/statusService3/* Which can be even better solution as you will keep files separated in folders and avoid ...


6

* is expanded by the shell before tar gets executed. So, making tar change the directory invalidates the arguments that * expanded into. You can simply tell tar to compress the directory instead: tar -czf /backupmnt/abc.tar.gz -C /backupmnt/statusService/ . The . represents the current directory, which will change when tar changes directories. This will ...


0

Anything involving ls is likely to produce unexpected results with special chars (space and other symbols). Any bashism (like arrays) isn't portable. Anything involving while read is usually slow. On the other hand, find is VERY flexible (lots of options to filter), it has [at least] two syntax which are fail safe for special chars... and It scales well on ...



Top 50 recent answers are included