I really don't know. I've had a lot of students who seem to think that you HAVE to cat to grep, and I can assure you, I do my best to correct them. Phil W On Mon, Aug 25, 2014 at 4:51 PM, Michael Havens wrote: > I get it! > > cat x | grep y > > is redundant. did I learn that when it wasn't redundant? if it never has > been redundant I wonder why I thought the pipe was needed? > > :-)~MIKE~(-: > > > On Mon, Aug 25, 2014 at 4:25 PM, Brian Cluff wrote: > >> You'll need to add some single quotes to keep the shell from interpreting >> your regex as shell code like this: >> >> grep -E 'error|fail' {make,install,check}.fail >> >> Without the single quotes you are telling the system to cat from your set >> of files and look for lines with the word error and pipe that to a program >> called fail. >> >> I found that I did have to add the -E even thought the man page says that >> in the GNU version of grep the basic and extended regular expressions are >> the same... it appears that is not the case in practice. >> >> Brian Cluff >> >> >> On 08/25/2014 12:56 PM, Michael Havens wrote: >> >>> 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 >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------- >>> 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 >