Re: Question about the return value of 'local'
On Fri, Dec 14, 2012 at 08:37:02AM +0100, Francis Moreau wrote: Then maybe an option should be added to 'local' to display the full description that one can get from the manual, or maybe change the behaviour of '-m' switch ? Almost every builtin command has a shorter and less informative description in the shell's 'help' than it does in the manual. The 'help' output is supposed to be a brief reminder of the syntax (e.g. which option letter was that...), not a repetition of the entire manual. I do sympathize with the difficulty of finding the relevant information in the manual sometimes, though, especially for builtins that are common words like 'set'.
Re: Question about the return value of 'local'
On Fri, Dec 14, 2012 at 2:21 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Fri, Dec 14, 2012 at 08:37:02AM +0100, Francis Moreau wrote: Then maybe an option should be added to 'local' to display the full description that one can get from the manual, or maybe change the behaviour of '-m' switch ? Almost every builtin command has a shorter and less informative description in the shell's 'help' than it does in the manual. The 'help' output is supposed to be a brief reminder of the syntax (e.g. which option letter was that...), not a repetition of the entire manual. Well, I actually use help(1) more than a shortcut to access quickly the relevant part of the manual than anything else. I regularly find that sailing across the manual is quite slow and annoying, but it's probably just me being lazy. -- Francis
Re: Question about the return value of 'local'
On 12/14/12 2:37 AM, Francis Moreau wrote: `help' is a quick reference -- a handy shortcut. The authoritative documentation is still the manual page and texinfo document. Then maybe an option should be added to 'local' to display the full description that one can get from the manual, or maybe change the behaviour of '-m' switch ? It was never a goal to duplicate the entire 70+-page manual inside bash. Why would I add options to each builtin to do that? The -m option to help was intended to display in a more familiar format. It's not a manual replacement, either. We already have the man page and the info file. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Question about the return value of 'local'
On 12/14/12 8:21 AM, Greg Wooledge wrote: I do sympathize with the difficulty of finding the relevant information in the manual sometimes, though, especially for builtins that are common words like 'set'. That's where the superior indexing and structure of the info file format demonstrate their advantages. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Questions to bash read builtin functionality
Hello list, One of our bash-scrips failed with very low frequency but randomly. The result was that exactly 1 byte was lost, so the string returned by read -t 1 was too short. The culprit seems to be the built-in read function itself, the probability of failure was about 1:10 in our case. After analysis and creation of a reliable reproducer, I'm not sure if this is a programming error in bash or a bug in our script as the result of suboptimal documentation. * Description: When read builtin is used with timeout setting, both with -t option or by setting the TMOUT environment variable, and the timeout occurs when some bytes of line were already received by bash, then those bytes are silently dropped. The next read returns the remainder of the line. A reproducer for Ubuntu precise is base64 -d BASE64-EOF | tar -xj QlpoOTFBWSZTWX5lCW0AAOl/xMwQAEB97f//NzycDn/v3uoggAhAAb1qpgGonpE9TagADQNN NaD1AAEomkyGpPKaADQGnqANNPUMmgABoDjJk00wmRkDAjE0YIwg0aYABBJIpphCZiaTNT0h o0aaAabU+Cv9dQPcQuSSaABIwQUkQNiTyBFsTAgcG2p0dIEciFV9EZfOok7RyV36nYqnFKSJ QMO4OAgwMtnhGwTmvZXHNLdCTPwVBN6uopct/CzRFdFSwWj8XJd8plU/gyNLrSlHLzYfHU7wYsAp zwbepqoV2GJYtNmAVZ1EYAEvzvgNCONxvrT0i4t65SLP1OkisWrcVnuxthOxKiZ5AktJbG2PmccG IoiA7Mok66IR2eEH5BgUD4BlrvrZmvBaQNmJU3IiUZIPgVFrrcVLRKQTROURx8e14EY40h2oT1c6 APc4kqdy25cqSZh5XelCN0X5EsQUUNkJV9UdtBmLxK8I7iZl/LQ7OQl5PL4YiYMZY04JEXVctElZ UilWStgdgM7PGQFCLDzmzYbdtnwEQMNC6ai+hyc0swZgkIgj1g05JTBy2CK9O6q+aC4GxU7Q2Uk0 qm1nbfmL0VDEEhOxVhDKbSUgKybpZgyBGTMPaEdGTlNZPC0soGO61Y8pBB/i7kinChIPzKEtoA== BASE64-EOF (export TMOUT=1; ./FragmentedSend.py | ./BashReadTest) * Discussion: The topic has two aspects: ** What is the intended read behavior in that case, is it a bug? Man-page is silent on that. So even if current behavior is intended, in my opinion the possible loss of data in read should be mentioned. -t timeout Cause read to time out and return failure if a complete line of input is not read within timeout seconds. time- out may be a decimal number with a fractional portion following the decimal point. This option is only effec- tive if read is reading input from a terminal, pipe, or other special file; it has no effect when reading from regular files. If timeout is 0, read returns success if input is available on the specified file descriptor, failure otherwise. The exit status is greater than 128 if the timeout is exceeded. **Mild security aspect: Since the TMOUT variable might not be filtered when invoking programs via sudo or within other restricted environments, it might be possible for an unprivileged user to invoke programs that use read in the same problematic way as I did. If he finds ways to influence the timing of the data reaching this function, he might be able to remove parts of the input or just cause random data corruption. I would guess, that it would be a quite rare case, e.g. when someone implemented following script for login checking cat [somefile] | sed [regex check for line sanity] | while read authConfLine; do Handle it done somefile content: root allprivs Remaining line name of admin userx someprivs FrankChangedItViaChFn userx allprivs FrankDidIt Any comments? Roman DI Roman Fiedler Engineer Safety Security Department Assistive Healthcare Information Technology AIT Austrian Institute of Technology GmbH Reininghausstrae 13/1 | 8020 Graz | Austria T +43(0) 50550 2957 | M +43(0) 664 8561599 | F +43(0) 50550 2950 roman.fied...@ait.ac.at | http://www.ait.ac.at/ FN: 115980 i HG Wien | UID: ATU14703506 This email and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient, please notify the sender by return e-mail or by telephone and delete this message from your system and any printout thereof. Any unauthorized use, reproduction, or dissemination of this message is strictly prohibited. Please note that e-mails are susceptible to change. AIT Austrian Institute of Technology GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor shall it be liable for any delay in its receipt.
Re: RFE: printf '%(fmt)T' prints current time by default
I think the ksh behavior is makes more sense so can we use the current time as the default? -Clark I agree that a null or empty argument as equivalent to -1 is a better default. 0 is identical to the current behavior for empty/unset, so no functionality is lost. That's not unreasonable. The current default is what Posix specifies for printf: Any extra c or s conversion specifiers shall be evaluated as if a null string argument were supplied; other extra conversion specifications shall be evaluated as if a zero argument were supplied. Additionally, an empty format in ksh is equivalent to the date(1) default for the current locale. So, LC_TIME=C; [[ $(printf '%()T') == $(date) ]] is true. Bash uses the strftime '%X' conversion, which is described as the locale's appropriate time representation. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Question about the return value of 'local'
On Friday, December 14, 2012 08:37:02 AM Francis Moreau wrote: On Thu, Dec 13, 2012 at 3:19 PM, Chet Ramey chet.ra...@case.edu wrote: On 12/13/12 3:56 AM, Francis Moreau wrote: I see thanks. Somehow I thought that help(1) would have given nothing more nothing less than what was described in the manual. `help' is a quick reference -- a handy shortcut. The authoritative documentation is still the manual page and texinfo document. Then maybe an option should be added to 'local' to display the full description that one can get from the manual, or maybe change the behaviour of '-m' switch ? Thanks. The best you could do (realistically) is manually keep the man document in sync with the help text for every individual builtin. Generating help output automatically would require completely changing the way builtin options are processed, because there aren't just arrays of options that could be mapped to descriptions. Bash loops over a condition for all available options for each argument. There are also a couple intentionally undocumented options (like declare -c), and some which can vary by how bash was built (like echo). Also the man document has all the formatting in it and can't be automatically generated from individual builtin help text easily, or vice versa. Zsh is way bigger than Bash and has no help system at all (unless I missed it in the dozen or so manpages...). Ksh has an unbelievably stupid way of accessing the help, though it tends to be even more comprehensive than the manpage. The options are automatically generated and the descriptions hardcoded to a central builtins.c file. (user-defined types are self- documenting). Most shell manuals follow about the same overall format and obviously borrow from one another. Some paragraphs are word-for-word identical between Bash and multiple other manuals. Best bet is to learn to navigate it quickly. -- Dan Douglas
Re: RFE: printf '%(fmt)T' prints current time by default
On Friday, December 14, 2012 09:57:11 AM Chet Ramey wrote: I think the ksh behavior is makes more sense so can we use the current time as the default? -Clark I agree that a null or empty argument as equivalent to -1 is a better default. 0 is identical to the current behavior for empty/unset, so no functionality is lost. That's not unreasonable. The current default is what Posix specifies for printf: Any extra c or s conversion specifiers shall be evaluated as if a null string argument were supplied; other extra conversion specifications shall be evaluated as if a zero argument were supplied. Ooh ok... hrm I didn't consider it's actually consistent with everything else this way. -- Dan Douglas
Re: Question about the return value of 'local'
I'm not trying to start a war, but ... Has anyone entertained the idea of getting rid of the man pages and the info system? Those are relics of the tty era. We have graphical interfaces today with capabilities that could enhance providing and then finding better information. Wouldn't a browser based html page be more helpful? Anyone on a non GUI could use lynx to read the pages, or make man pull up lynx to keep the command structure the same. The basic page could be what man is now, more or less, and the ability to drill down would provide more and more information the deeper you drill. Code snippets could highlight idiosyncratic behavior at boundary conditions while other examples demonstrate the main emphasis. A WIKI set up could allow people to augment the docs with some authority then editing the content to keep it up to some standard. Greg's site is excellent, as are several others, and that's the issue. There is no one authoritative place to go to get the OFFICIAL docs in a modern form. Who wants to learn how to write and submit man or info docs when the future is clearly html, especially when neither man nor info has the rendering capability html has? If the Linux community as a whole missed one technical release cycle to instead concentrate on properly documenting what already exists, the effort would pay off in spades for all future releases. On Fri, Dec 14, 2012 at 10:15 AM, Dan Douglas orm...@gmail.com wrote: On Friday, December 14, 2012 08:37:02 AM Francis Moreau wrote: On Thu, Dec 13, 2012 at 3:19 PM, Chet Ramey chet.ra...@case.edu wrote: On 12/13/12 3:56 AM, Francis Moreau wrote: I see thanks. Somehow I thought that help(1) would have given nothing more nothing less than what was described in the manual. `help' is a quick reference -- a handy shortcut. The authoritative documentation is still the manual page and texinfo document. Then maybe an option should be added to 'local' to display the full description that one can get from the manual, or maybe change the behaviour of '-m' switch ? Thanks. The best you could do (realistically) is manually keep the man document in sync with the help text for every individual builtin. Generating help output automatically would require completely changing the way builtin options are processed, because there aren't just arrays of options that could be mapped to descriptions. Bash loops over a condition for all available options for each argument. There are also a couple intentionally undocumented options (like declare -c), and some which can vary by how bash was built (like echo). Also the man document has all the formatting in it and can't be automatically generated from individual builtin help text easily, or vice versa. Zsh is way bigger than Bash and has no help system at all (unless I missed it in the dozen or so manpages...). Ksh has an unbelievably stupid way of accessing the help, though it tends to be even more comprehensive than the manpage. The options are automatically generated and the descriptions hardcoded to a central builtins.c file. (user-defined types are self- documenting). Most shell manuals follow about the same overall format and obviously borrow from one another. Some paragraphs are word-for-word identical between Bash and multiple other manuals. Best bet is to learn to navigate it quickly. -- Dan Douglas -- Bill Gradwohl
Re: Question about the return value of 'local'
On 12/14/2012 12:07 PM, Bill Gradwohl wrote: I'm not trying to start a war, but ... Has anyone entertained the idea of getting rid of the man pages and the info system? Those are relics of the tty era. We have graphical interfaces today with capabilities that could enhance providing and then finding better information. Wouldn't a browser based html page be more helpful? Anyone on a non GUI could use lynx to read the pages, or make man pull up lynx to keep the command structure the same. The basic page could be what man is now, more or less, and the ability to drill down would provide more and more information the deeper you drill. Code snippets could highlight idiosyncratic behavior at boundary conditions while other examples demonstrate the main emphasis. A WIKI set up could allow people to augment the docs with some authority then editing the content to keep it up to some standard. Greg's site is excellent, as are several others, and that's the issue. There is no one authoritative place to go to get the OFFICIAL docs in a modern form. Who wants to learn how to write and submit man or info docs when the future is clearly html, especially when neither man nor info has the rendering capability html has? If the Linux community as a whole missed one technical release cycle to instead concentrate on properly documenting what already exists, the effort would pay off in spades for all future releases. Die Infidel! ;-) You will find no problem viewing man or info pages in html. They are all over the web for a reason. TeXInfo was designed to produce either info files or DVI. From the DVI, you can do anything you want, including convert to html. I'm not wild about software (or associated docs) that's maintained in a wiki. It kinda violates the notion of a stable picture of what's in a release. Steve Orr
Re: Question about the return value of 'local'
On 12/14/2012 06:07 PM, Bill Gradwohl wrote: I'm not trying to start a war, but ... Has anyone entertained the idea of getting rid of the man pages and the info system? Those are relics of the tty era. Don't make the error of confusing the texinfo system with just the info format. I, for one, *never* read pages in the info format. However, I never had any problem reading the official documentation of GNU packages -- I just read the HTML version that is generated by exactly the same texinfo sources used to generate the info pages (as well as the PDF manuals for printing are). [SNIP] A WIKI set up could allow people to augment the docs with some authority then editing the content to keep it up to some standard. Greg's site is excellent, as are several others, and that's the issue. There is no one authoritative place to go to get the OFFICIAL docs in a modern form. What's wrong with http://www.gnu.org/software/bash/manual/bashref.html? Or, if you want a local version, just install the 'bash-doc' package on Debian (or the equivalent package that surely comes with other distros). Who wants to learn how to write and submit man or info docs when the future is clearly html, especially when neither man nor info has the rendering capability html has? Nobody writes info directly; one writes Texinfo, and that can be automatically translated to info, html, PDF (and PostScript and DVI too, not that it matters today). And I must say that I find the HTML generated from texinfo sources of high quality (nor perfect, granted, but definitely good enough). Writing something directly in HTML seems absurd today, IMHO. We want higher-level languages, and Texinfo is an excellent example of such a language, at least for most technical manuals. If the Linux community as a whole missed one technical release cycle to instead concentrate on properly documenting what already exists, the effort would pay off in spades for all future releases. I don't see how HTML-only documentation would be an improvement; it would be a huge step back, actually. Regards, Stefano
Re: Question about the return value of 'local'
On 12/14/2012 06:58 PM, Bill Gradwohl wrote: My point was to DESIGN for html and the rich environment it offers, not to try to convert a Model T into a Mercedes. I'm not wild about a wiki either, if its a free for all. If on the other hand, it is a submission platform that gets reviewed and edited by the developers then it's possibly of benefit, especially for examples. The best technical document I ever encountered was the DOS C compiler from Microsoft over 20 years ago. At about 1.5 thick, the book that came with it was excellent. I kept the book long after I ditched the compiler. Every item listed in the index had sample code associated with it that not only showed how to use the item, but also provided examples for the boundary conditions that reinforced what the documentation said. AFAICS, there's nothing in Texinfo preventing a developer from writing such an excellent documentation; what prevents it is typically the fact that writing good documentation is hard, subtly complex, time consuming, and tiring. No silver bullet for that; a tool or a format can only remove the non-essential, mundane difficulties, not the intrinsic ones. Absolutely excellent documentation. It used the KR style but applied it to the entire subroutine library. Regards, Stefano
Re: RFE: printf '%(fmt)T' prints current time by default
On 12/14/12 12:03 PM, Dan Douglas wrote: On Friday, December 14, 2012 09:57:11 AM Chet Ramey wrote: I think the ksh behavior is makes more sense so can we use the current time as the default? -Clark I agree that a null or empty argument as equivalent to -1 is a better default. 0 is identical to the current behavior for empty/unset, so no functionality is lost. That's not unreasonable. The current default is what Posix specifies for printf: Any extra c or s conversion specifiers shall be evaluated as if a null string argument were supplied; other extra conversion specifications shall be evaluated as if a zero argument were supplied. Ooh ok... hrm I didn't consider it's actually consistent with everything else this way. I'm not saying I can't change the %T default -- I probably will, and it will be documented as an exception in the man page. The above is the explanation for the status quo. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: shouldn't /+(??) capture 2 letter files only?
i wanted to move a bunch of files directories, all except a certain few, so i figured i'd use !(this|or|that). so first i looked to see if +(this|or|that) isolated what i expected... you would want /@(??) or simply /??, since there's no need for extglob for that. well what i actually wanted was to conjure an expression that selected a small few files, and then invert the expression, in particular i wanted to isolate all 2 letter names plus a few other names, and then invert, so that the aforementioned were not in the selection. perhaps that's just a tad beyond what a bash expression can do (without writing a loop)?
why does errexit exist in its current utterly useless form?
I recently worked on a project involving many bash scripts, and I've been
trying to use errexit to stop various parts of a script as soon as anything
returns a non-0 return code. As it turns out, this is an utterly useless
endeavour. In asking this question on this forum, I hope somebody out there can
help me, who understands bash, POSIX, and why decisions were made to arrive at
the current situation.
To recapitulate, errexit is turned on by set -e or set -o errexit. This is
what TFM says about it:
Exit immediately if a pipeline (see Pipelines), which may consist of a single
simple command (see Simple Commands), a subshell command enclosed in
parentheses (see Command Grouping), or one of the commands executed as part of
a command list enclosed by braces (see Command Grouping) returns a non-zero
status. The shell does not exit if the command that fails is part of the
command list immediately following a while or until keyword, part of the test
in an if statement, part of any command executed in a or || list except the
command following the final or ||, any command in a pipeline but the last,
or if the command’s return status is being inverted with !. A trap on ERR, if
set, is executed before the shell exits. This option applies to the shell
environment and each subshell environment separately (see Command Execution
Environment), and may cause subshells to exit before executing all the commands
in the subshell.
Let's leave pipelines aside, because that adds more complexity to an already
messy problem. So we're talking just simple commands.
My initial gripe about errexit (and its man page description) is that the
following doesn't behave as a newbie would expect it to:
set -e
f() {
false
echo NO!!
}
f || { echo f failed 2; exit 1; }
Above, false usually stands for some complicated command, or part of a
sequence of many commands, and echo NO!! stands for a statement releasing a
lock, for instance. The newbie assumes that the lock won't be released unless
executing f goes well. Moreover, the newbie likes many error messages, hence
the extra message in the main script.
Running it, you get:
NO!!
First of all, f is called as the LHS of ||, so we don't want the entire shell
to crash if f returns non-0. That much, a not entirely dumb newbie can
understand. But, lo and behold, NO!! gets printed. Do you see this explained in
TFM, because I don't.
Question 1: Is this a bug in the manual itself?
As the hours of debugging pass by, the newbie learns about shells and subshells
and subprocesses and what not. Also, apparently that one can see the current
shell settings with $- or $SHELLOPTS. So the newbie changes f to:
f() {
echo $-
false
echo NO!!
}
You get:
ehB
NO!!
This is now getting confusing: errexit seems to be active as bash executes f,
but still it doesn't stop.
Question 2: Is this a bug in how $- is maintained by bash?
Next, the newbie thinks, oh, I'll just set errexit again inside f. How about:
f() {
set -e
echo $-
false
echo NO!!
}
You get:
ehB
NO!!
At this point, the newbie thinks, perhaps errexit isn't working after all.
Question 3: Under the current design (which I consider flawed), why doesn't
bash at least print a warning that errexit is not active, when the user tries
to set it?
As even more hours pass by, the newbie learns things about various other
shells, POSIX mode, standards, etc. Useful things, but arguably useless for the
task at hand. So, from what I the newbie gathered so far...
One can work around this by using to connect all statements in f, or using
|| return 1 after each of them. This is ok if f is 2 lines, not if it's 200.
I also learned one can actually write a tiny function which tests if the ERR
signal is active, and if it is not, to executed the invoking function (f) in a
different shell, passing the entire environment, including function defs, with
typeset. This is really awkward, but possible. However, it only works for
functions, not for command lists run in a subshell, as in:
( false; echo NO!! ) || { echo failed 2; exit 1; }
The common suggestion I see on various forums is- don't use errexit. I now
understand this from a user perspective, and that's why I call errexit utterly
useless in the subject. But, if I may ask, why is bash in this position?
Question 4: Back to the original f, why did bash (or even POSIX) decide to
protect the false statement? Protecting f is clearly necessary, for otherwise
|| would be useless. But why the false?
Question 4a (perhaps the same): TFM says: the shell does not exit if the
command that fails is part of the command list immediately following a while.
Why protect commands in such a list other than the last?
And independent of the question(s) 4, the last one:
Question 5: Even assuming bash/POSIX decides to protect lists of commands where
only the last is tested, why does bash entirely disable the errexit option?
Playing around with it, it seems to me
Re: why does errexit exist in its current utterly useless form?
On 12/14/2012 04:07 PM, matei.da...@gmail.com wrote:
I recently worked on a project involving many bash scripts, and I've been
trying to use errexit to stop various parts of a script as soon as anything
returns a non-0 return code. As it turns out, this is an utterly useless
endeavour. In asking this question on this forum, I hope somebody out there
can help me, who understands bash, POSIX, and why decisions were made to
arrive at the current situation.
Short answer: historical compatibility. 'set -e' has been specified to
behave the way it did 30 years ago in one reference implementation, and
while you can argue till you are blue in the face that the reference
implementation is not intuitive, you have to at least appreciate that
having a standard means you are likely to get the same (non-intuitive)
behavior among several competing shell implementations that all strive
to conform to POSIX.
Personal recommendation: 'set -e' is probably not worth your effort,
especially not if you use shell functions.
My initial gripe about errexit (and its man page description) is that the
following doesn't behave as a newbie would expect it to:
set -e
f() {
false
echo NO!!
}
f || { echo f failed 2; exit 1; }
Indeed, the correct behavior mandated by POSIX (namely, that 'set -e' is
completely ignored for the duration of the entire body of f(), because f
was invoked in a context that ignores 'set -e') is not intuitive. But
it is standardized, so we have to live with it.
Question 4: Back to the original f, why did bash (or even POSIX) decide to
protect the false statement?
Because once you are in a context that ignores 'set -e', the historical
behavior is that there is no further way to turn it back on, for that
entire body of code in the ignored context. That's how it was done 30
years ago, before shell functions were really thought about, and we are
stuck with that poor design decision.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: shouldn't /+(??) capture 2 letter files only?
On 12/14/2012 11:29 PM, gregrwm wrote: well what i actually wanted was to conjure an expression that selected a small few files, and then invert the expression, in particular i wanted to isolate all 2 letter names plus a few other names, and then invert, so that the aforementioned were not in the selection. perhaps that's just a tad beyond what a bash expression can do (without writing a loop)? (shopt -s extglob) echo !(??|foo|bar) or if you want to loop over those files, for FILE in !(??|foo|bar); do echo $FILE; done and so on. Rene.
Re: shouldn't /+(??) capture 2 letter files only?
echo !(??|foo|bar) precisely where i started this thread, !(??)
Re: shouldn't /+(??) capture 2 letter files only?
On 12/15/2012 02:37 AM, gregrwm wrote: echo !(??|foo|bar) precisely where i started this thread, !(??) Not sure if I understand you correctly because you indeed mentioned the !(foo|bar|baz) syntax in your first post -- but the thread was actually about +(??) ... That is, are you satisfied with the answer(s) now or is anything left? Rene.
Re: shouldn't /+(??) capture 2 letter files only?
On Fri, Dec 14, 2012 at 8:37 PM, gregrwm backuppc-us...@whitleymott.netwrote: echo !(??|foo|bar) precisely where i started this thread, !(??) +(??) and !(??) are completely different things. !(??) was never mentioned in the original question, and should work as expected.
