I have 3 files, make.fail, install.fail, and check.fail. I want to check for two words in those files: error and fail. would this work? cat {make,install,check}.fail | grep -i error|fail I was told to put the 'E' option in to grep. Looking at the man page it seems that the E option is only useful if I were greping for something that begins with a '{'. AM I misreading the man page? man quote: GNU grep -E attempts to support traditional usage by assuming that { is not special if it would be the start of an invalid interval specification. For example, the command grep -E '{1' searches for the two-character string {1 instead of reporting a syntax error in the regular expression. POSIX allows this behavior as an extension, but portable scripts should avoid it. :-)~MIKE~(-: On Mon, Aug 25, 2014 at 12:24 PM, Michael Havens wrote: > you guys are so helpful! Thanks. > > :-)~MIKE~(-: > > > On Sun, Aug 24, 2014 at 7:40 PM, Jon Kettenhofen wrote: > >> I like visible proofs, so here's a test I ran: >> (terminal output was as is shown) >> >> [jon@localhost ~]$ rm temp >> [jon@localhost ~]$ echo >>temp >> [jon@localhost ~]$ echo $? >> 0 >> [jon@localhost ~]$ cat temp >> >> [jon@localhost ~]$ echo >>temp 2>&1 >> [jon@localhost ~]$ echo $? >> 0 >> [jon@localhost ~]$ cat temp >> >> >> [jon@localhost ~]$ >> >> as you can see, no errors and the single ">" did not erase the file when >> used in this manner. So Mike's script should work as intended >> at least if there is no stderr output. >> >> but suppose there was an error? (apologizing for the length of ...) >> >> [jon@localhost ~]$ echo "echo" >test >> [jon@localhost ~]$ echo "ls temp2" >>test >> [jon@localhost ~]$ # test ls of non-existent file >> [jon@localhost ~]$ ls temp2 >> ls: cannot access temp2: No such file or directory >> [jon@localhost ~]$ echo $? >> 2 >> [jon@localhost ~]$ # see, we get both an error and stderr message >> [jon@localhost ~]$ # so >> [jon@localhost ~]$ mv test test.sh >> [jon@localhost ~]$ chgmod +x test.sh >> bash: chgmod: command not found... >> [jon@localhost ~]$ chmod +x test.sh >> [jon@localhost ~]$ # i'm not perfect! >> [jon@localhost ~]$ rm temp >> [jon@localhost ~]$ ./test.sh >>temp >> ls: cannot access temp2: No such file or directory >> [jon@localhost ~]$ echo $? >> 2 >> [jon@localhost ~]$ cat temp >> >> [jon@localhost ~]$ ./test.sh >>temp 2>&1 >> [jon@localhost ~]$ echo $? >> 2 >> [jon@localhost ~]$ cat temp >> >> >> ls: cannot access temp2: No such file or directory >> [jon@localhost ~]$ >> >> as you can see, Mike's script will work as he apparently intended, >> providing he's using a modern version of bash. >> >> >> >> On 08/24/2014 09:56 PM, James Mcphee wrote: >> >>> you've said make, append stdout (default file descriptor 1) to file >>> make.fail, assign stderr (default filedescriptor 2) the same >>> filedescriptor as stdout. So... If the intent was to have both stderr >>> and stdout append make.fail, then it is correct. >>> >>> >>> On Sun, Aug 24, 2014 at 6:06 PM, Michael Havens >> > wrote: >>> >>> what I really need to know is will this: >>> >>> make>>make.fail 2>&1 >>> >>> send stderr and stdout to the file 'make.fail' or did I write it >>> incorrectly? >>> >>> :-)~MIKE~(-: >>> >>> >>> On Sun, Aug 24, 2014 at 2:56 PM, Brian Cluff >> > wrote: >>> >>> the > will delete any file that it points at even if the command >>> doesn't actually output anything. It will even delete the file >>> is the command doesn't exist like if you type grep as gerp >>> >file, file will still be created/overwritten. >>> >>> If you want to make sure that your command doesn't overwrite any >>> existing files you have to set the noclobber option like: >>> $ set -o noclobber >>> >>> A good trick to know: >>> You can use the > to delete the contents of a file without >>> having to delete and recreate the file by simply doing this: >>> $ >yourfile >>> >>> Brian Cluff >>> >>> >>> On 08/24/2014 02:36 PM, Michael Havens wrote: >>> >>> I have a question about redirections: >>> >>> make>>make.fail 2>&1 >>> >>> tells it make and then to send (>) stderr (2) to stdout (1) >>> and also to >>> send stdout that way also (&1). finally all of that gets >>> sent to a file >>> named make.fail (>>). Isn't '>>' actually 'append' whereas >>> '>' would >>> work just as well so long as the file didn't already exist? >>> If the file >>> did exist would I get an error or would the file be >>> overwritten? >>> :-)~MIKE~(-: >>> >>> >>> ------------------------------__--------------------- >>> PLUG-discuss mailing list - >>> PLUG-discuss@lists.phxlinux.__org >>> >>> >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/__mailman/listinfo/plug-discuss >>> >>> >>> ------------------------------__--------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.__org >>> >>> >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/__mailman/listinfo/plug-discuss >>> >>> >>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> >>> >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> >>> -- >>> James McPhee >>> jmcphe@gmail.com >>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >> > >