make
Phil Waclawski
phil.waclawski at mesacc.edu
Mon Aug 25 17:07:09 MST 2014
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 <bmike1 at gmail.com> 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 <brian at snaptek.com> 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 <bmike1 at gmail.com
>>> <mailto:bmike1 at gmail.com>> wrote:
>>>
>>> you guys are so helpful! Thanks.
>>>
>>> :-)~MIKE~(-:
>>>
>>>
>>> On Sun, Aug 24, 2014 at 7:40 PM, Jon Kettenhofen <subs at kexsof.com
>>> <mailto:subs at kexsof.com>> wrote:
>>>
>>> I like visible proofs, so here's a test I ran:
>>> (terminal output was as is shown)
>>>
>>> [jon at localhost ~]$ rm temp
>>> [jon at localhost ~]$ echo >>temp
>>> [jon at localhost ~]$ echo $?
>>> 0
>>> [jon at localhost ~]$ cat temp
>>>
>>> [jon at localhost ~]$ echo >>temp 2>&1
>>> [jon at localhost ~]$ echo $?
>>> 0
>>> [jon at localhost ~]$ cat temp
>>>
>>>
>>> [jon at 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 at localhost ~]$ echo "echo" >test
>>> [jon at localhost ~]$ echo "ls temp2" >>test
>>> [jon at localhost ~]$ # test ls of non-existent file
>>> [jon at localhost ~]$ ls temp2
>>> ls: cannot access temp2: No such file or directory
>>> [jon at localhost ~]$ echo $?
>>> 2
>>> [jon at localhost ~]$ # see, we get both an error and stderr
>>> message
>>> [jon at localhost ~]$ # so
>>> [jon at localhost ~]$ mv test test.sh
>>> [jon at localhost ~]$ chgmod +x test.sh
>>> bash: chgmod: command not found...
>>> [jon at localhost ~]$ chmod +x test.sh
>>> [jon at localhost ~]$ # i'm not perfect!
>>> [jon at localhost ~]$ rm temp
>>> [jon at localhost ~]$ ./test.sh >>temp
>>> ls: cannot access temp2: No such file or directory
>>> [jon at localhost ~]$ echo $?
>>> 2
>>> [jon at localhost ~]$ cat temp
>>>
>>> [jon at localhost ~]$ ./test.sh >>temp 2>&1
>>> [jon at localhost ~]$ echo $?
>>> 2
>>> [jon at localhost ~]$ cat temp
>>>
>>>
>>> ls: cannot access temp2: No such file or directory
>>> [jon at 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
>>> <bmike1 at gmail.com <mailto:bmike1 at gmail.com>
>>> <mailto:bmike1 at gmail.com <mailto:bmike1 at gmail.com>>> 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
>>> <brian at snaptek.com <mailto:brian at snaptek.com>
>>> <mailto:brian at snaptek.com <mailto:brian at snaptek.com>>>
>>>
>>> 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 at lists.phxlinux.____org
>>> <mailto:PLUG-discuss at lists.__phxlinux.org
>>>
>>> <mailto:PLUG-discuss at lists.phxlinux.org>>
>>>
>>> To subscribe, unsubscribe, or to change your
>>> mail settings:
>>> http://lists.phxlinux.org/____mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/__mailman/listinfo/plug-discuss>
>>>
>>> <http://lists.phxlinux.org/__mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/mailman/listinfo/plug-discuss>>
>>>
>>> ------------------------------
>>> ____---------------------
>>> PLUG-discuss mailing list -
>>> PLUG-discuss at lists.phxlinux.____org
>>> <mailto:PLUG-discuss at lists.__phxlinux.org
>>>
>>> <mailto:PLUG-discuss at lists.phxlinux.org>>
>>>
>>> To subscribe, unsubscribe, or to change your mail
>>> settings:
>>> http://lists.phxlinux.org/____mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/__mailman/listinfo/plug-discuss>
>>>
>>>
>>>
>>> <http://lists.phxlinux.org/__mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/mailman/listinfo/plug-discuss>>
>>>
>>>
>>>
>>> ------------------------------__---------------------
>>> PLUG-discuss mailing list -
>>> PLUG-discuss at lists.phxlinux.__org
>>> <mailto:PLUG-discuss at lists.phxlinux.org>
>>> <mailto:PLUG-discuss at lists.__phxlinux.org
>>>
>>> <mailto:PLUG-discuss at lists.phxlinux.org>>
>>>
>>> To subscribe, unsubscribe, or to change your mail
>>> settings:
>>> http://lists.phxlinux.org/__mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/mailman/listinfo/plug-discuss>
>>>
>>>
>>>
>>>
>>> --
>>> James McPhee
>>> jmcphe at gmail.com <mailto:jmcphe at gmail.com>
>>> <mailto:jmcphe at gmail.com <mailto:jmcphe at gmail.com>>
>>>
>>>
>>>
>>>
>>> ------------------------------__---------------------
>>> PLUG-discuss mailing list -
>>> PLUG-discuss at lists.phxlinux.__org
>>> <mailto:PLUG-discuss at lists.phxlinux.org>
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/__mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/mailman/listinfo/plug-discuss>
>>>
>>>
>>> ------------------------------__---------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.__org
>>> <mailto:PLUG-discuss at lists.phxlinux.org>
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/__mailman/listinfo/plug-discuss
>>> <http://lists.phxlinux.org/mailman/listinfo/plug-discuss>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss at 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 at 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 at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20140825/81105f4d/attachment.html>
More information about the PLUG-discuss
mailing list