Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That is not your real problem, you can extend my example from above to
Code:
for f in `ls /path/to/the/directory/[!file_pattern]*`; do echo "$f"; done
then call the script from wherever you like.
But if you plan to re-use this under changing conditions, it will be interesting, how you compose your pattern each time. I am not really sure, but have a bad feeling about the negation. It may introduce more potential for false positives than without... Maybe it is wiser to move the unwanted files away from the directory, then just process the remainder...
This is really strange; as if I had made some bad experience with such a match one time but cannot remember any more...
For both posts 2, 4 and 5 one will hope that none of the output of `` or $() is separated by white space, otherwise the command will be working on something that does not exist.
I have to say that from the original example provided I am not sure I understand the task?
Code:
ls | grep -v \^pattern.\ ${A}
The above makes little to no sense. List all items in the current directory and negate a grep on the output that does not contain '^pattern /path/to/abc.txt'. My question is why you would have
any files or directories that would contain such a pattern?
Are you able to perhaps explain, perhaps with example data, exactly what it is you are after?
To handle files with spaces in the names, this variant should work.
Code:
ls /path/to/*.txt | awk '!/pattern/' | while read FN; do <command ${FN}>; done
But I prefer to avoid having "while read" get data from a pipeline whenever possible though. I've run into problems where some commands inside the "do/done" loop can screw up the data in the pipeline, essentially terminating the loop after the first time through.
In my experience it will either work or break every time, so it's easy enough to test before you start using the script. But I still prefer to avoid that sort of construct where I can.
It's a bit misleading to say that negates a pattern. The ! complements a character set, so [!pattern]* matches any file that doesn't start with one a,e,n,p,r, or t. The `ls ...` is redundant, you can get the same with
Code:
for f in [!pattern]*; do echo "$f"; done
except that this version can handle file names with spaces.
Quote:
[ ]
Matches any one of the enclosed characters. ... If the first character following the [ is a ! or a ^ then any character not enclosed is matched.
The ! complements a character set, so [!pattern]* matches any file that doesn't start with one a,e,n,p,r, or t.
Thank you. This distinction is important.
Quote:
If you enable extglob, !(pattern-list) gives you actual pattern negation.
The specific needs of the OP had not been too clear, in this respect. Anyway, it happens often, that we respond to a question, and many follow, before the OP explains why all our responses are not quite what he needs.
The original example lets much space for imagination. A temptation that I try to resist.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.