14
5
What is the meaning of following ls
command?
ls -l *\:2,*T
ls
= list-l
= long (list)*T
probably meansT
at the end
But what about that *\:2
and the comma?
14
5
What is the meaning of following ls
command?
ls -l *\:2,*T
ls
= list-l
= long (list)*T
probably means T
at the endBut what about that *\:2
and the comma?
25
*\:2,*T
is the glob pattern of files to list. To understand it, we need to remember a few things:
:
has to be escaped in the shell, becoming \:
So *\:2,*T
would e.g. match a file called TranscationNumber:2,EventType:XYT
EDIT
From the comments, the necessity (or not) of escaping the :
needs a few words: It is not strictly necessary to escape the :
sign, but bash itself suggests it when autocompleting.
14
List all files that match the wildcard pattern *:2,*T
There the wildcard *
matches anything (any number of all possible characters)
:2,
are characters that need to be present in the file/directory names.
The colon :
is a special character that needs to be escaped, hence the form of \:2,
.
The file/directory names need to end with a T
.
File names that would match would be
:2,T
a:2,T
a:2,bT
abbY-$fafaf:2,<hskjhsgdfhjk>T
1There's nothing special about :, it doesn't need to be escaped. – Kevin – 2017-08-18T19:05:45.730
@Kevin bash auto-completion automatically escapes the colon in file/directory name patterns, because is included in the list of COMP_WORDBREAK
environment values that get set by default. - So it is indeed not an actual special character, but when you use autocompletion on the commandline and want/need to match filenames with a colon , it does need to be escaped. – HBruijn – 2017-08-23T07:39:59.357
9
As others have noted, this will list in long format, files containing :2
, and ending in T
This looks like a search in a Maildir folder for files that were deleted (trashed). However, for robustness it should have had another *
at the end, though. New flags with a later alphabetical position could be added, and Dovecot for instance adds another field with the file size at the end.
3
Thank you, both Eugen and HBruijn. I suspected some complicated globbing pattern, but actually it should just match the colon and the comma, which I did not think of when working with files. Now, the command totally makes sense: list all email files in the Maildir directories, which are marked as "Deleted" (T). Btw. The number 2 means Maildir in version 2 (cf https://wiki2.dovecot.org/MailboxFormat/Maildir).
– jugmac00 – 2017-08-18T11:20:35.04011Since when does
:
have to be escaped? – Barmar – 2017-08-18T17:48:20.6237
:
doesn't need to be escaped. It is only special in specific circumstances (when used as a command), not in glob patterns. The\:
is equivalent to:
, escaping makes no difference. – terdon – 2017-08-18T18:11:30.147@terdon I was wondering in which case it would be interesting to have
– Aaron – 2017-08-19T00:59:04.973\:
as a command, and found out thatbash
still seems to parse\:
as the NOP command. See this ideone. I guess it was different in older versions of bash or other shells?@Barmar Edited my answer, thanks for pointing this out! – Eugen Rieck – 2017-08-19T01:33:02.270
1@Aaron, it's not exactly no-op: the shell will still process variable substitutions, particularly the assignment variety (i.e. to set default values):
unset var; : ${var:=x}; echo $var
– glenn jackman – 2017-08-19T13:23:40.440@Aaron I wouldn't expect
– terdon – 2017-08-22T15:15:13.373\:
to protect if from being recognized as a command since that is another common construct used, for example, to ignore aliases. On the other hand, tab completion on a file whose name has a:
results in\:
. I don't know why that would happen but I would guess that it is historical and that older shells would choke on it. I tested on bash, dash, tcsh and ksh and all of them had no issue dealing with:
. Presumably, some older shells did.@terdon thanks, I didn't know about that use of backslash, I would have used
command
orbuiltin
to achieve the same effect. There's definitely something weird with the auto-completion : I've tested with bash on both a Cygwin and an RHEL and got some weird behaviors, including the one you mention, the inability to complete just after the:
or even worse, completion proposals based only on the part following the:
(i.e. completion aftertest:te
proposing every file starting withte
). Looks like escaping them can be a good idea. – Aaron – 2017-08-22T16:42:11.4203@terdon & @Aaron The colon
:
is part of the default values for theCOMP_WORDBREAKS
environment variable. In Bash autocompletion those characters are used as word separators by the read line library and a file-name containing a colon should of course be a single word. Hence the reason that bash autocompletion requires the colon to be escaped, although otherwise it is "mostly" not a special character... – HBruijn – 2017-08-23T07:49:04.980