Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then 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.
I tried your command with the same result. Then I started chopping parts off of it until it worked. I found that if you change
Code:
....... -print | sed .......
to
Code:
....... -exec sed .......
then the error with the find command goes away and an error with sed is reported. Yay!!! Now I call that progress!
I can't tell if this was intended to be helpful....
As to the original question, here's a guess:
Running "live", the pathname can be abbreviated based on where you are when you run the command. In a script, maybe the pathname can become ambiguous. I'm guessing that putting in the full pathname will work.
Essentially the part of the script that isn't working is the part that should generate a large listing of all files (specific to the file extensions). The input of the script should be a directory. Assume error checking is done in the real script. But to simplify things, i'm just going to paste the main issue.
Your last suggestion would never work because the 'find -exec' command expects a {} and a \; which I could never supply. Thus the reason is because i'm looking for information (with find) that causes conflicts with the 'sed' wildcards... this i need to escape them.
Naturally i didn't expect you to have preformed osmosis and figure that one out. I thought maybe my issue was common. But now that i've added a bit more complexity to the issue.... can it still be done?
Chris
EDIT: Thanks to stress_junkies attention, i forgot to update the CMD= line... (above is what i meant it to read)
lead2gold, your last code segment did not have the dot following the find command. I will assume that the second code segment is incorrect. I will update this post with more information if I have anything to report.
I will work on the sed command now. Since I've never used sed but I am familiar with vi so this will be new territory.
(Some time later.)
After a bit of experimenting it seems that the find command doesn't like to have anything to do with another command on the same line. Even a command delimiter, the semicolon, will cause that error.
Code:
CMD="find . -print ;"
Maybe you can put the results of the find command into a file or a FIFO for sed to pick up. That's as far as I can go since I've never used FIFOs and reading the man page for sed was enough new stuff for one day.
Last edited by stress_junkie; 07-16-2007 at 07:08 PM.
Essentially the part of the script that isn't working is the part that should generate a large listing of all files (specific to the file extensions). The input of the script should be a directory. Assume error checking is done in the real script. But to simplify things, i'm just going to paste the main issue.
Your last suggestion would never work because the 'find -exec' command expects a {} and a \; which I could never supply. Thus the reason is because i'm looking for information (with find) that causes conflicts with the 'sed' wildcards... this i need to escape them.
Naturally i didn't expect you to have preformed osmosis and figure that one out. I thought maybe my issue was common. But now that i've added a bit more complexity to the issue.... can it still be done?
Chris
EDIT: Thanks to stress_junkies attention, i forgot to update the CMD= line... (above is what i meant it to read)
(Rahul Sinha)
Simply enclosing the wildcard in single quotes makes it work! e.g.
are you sure the command really retrieved anything? I agree we do not get the error message anymore, but I guess the command wouldn't retrieve any results at all. I mean, it didn't for me !!! Instead of single quotes, we may need to use double quotes around cronfile* and then append with .txt
This worked for me, and to explain more on the situations where we stumble upon this error. Assume, we have 2 files
1. c_a.xyz
2. c_b_a.xyz
in current directory.
If we do, find . -iname c*.xyz, we get the error.
If we do, find . -iname 'c*.xyz', no files are listed. So, I figured out, the solution would be to use find . -iname "c*".txt
This is just a small snippit from a larger script; but this is the snippet of the part that doesn't work. Does anyone have any ideas?
Thanks in advance!
Chris
I had a similar problem. I found that adding quotes " ", back-ticks ' ', and an escape character \. Had no effect. The find worked in one script and not another. The cause of my "error" was that one script had to be run as root but the other could be run by a user.
So, there was nothing wrong with the structure of the find statement!
You have probably solved your problem but this reply is submitted now for the benefit of anyone searching for a solution!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.