 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 2010 18:03:30 -0300, Nicolas Alvarez wrote:
> Which of the lines in this chat log contains a normal message, as
> opposed to information like "Jim has joined #povray" or "Logfile
> started"?
>
> I piped the result of that grep into 'sed' to extract only the username,
> then sort | uniq -c | sort -n, and I got an ordered list of who talks
> the most in the chatroom :)
Yep, that would work too. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> Warp wrote:
>>> So what? I'm not interested in how much disk space the file is taking.
>> But most other people are. Hence the default UI.
>
> Default UI? There is no option to make it work in a different way.
There's no option included in the software as it comes from the manufacturer
to make it work differently, no.
> It's not
> the default UI, it's the *only* UI.
"Default" means "unless you do something." :-)
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail com> wrote:
> > fgrep '#include "header.hh"' *.cc
> There could be more spaces.
> grep '#include[[:space:]]\+"header.hh"' *.cc
Well, since it's not possible to have two #-commands in the same line,
and having anything else between the #include and the file name is unlikely,
you could just as well do it line:
grep '#include.*"header.hh"' *.cc
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2010 6:47 PM, Jim Henderson wrote:
> On Fri, 23 Apr 2010 06:26:24 +0100, Stephen wrote:
>
>>> Not so much, though, I prefer the darkness generally. ;-)
>>>
>>>
>> Have you checked your reflection in a mirror, lately?
>
> It's too dark for mirrors. ;-)
>
> Jim
LOL
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Yesterday, the 'parted' tool was giving me a totally cryptic error message.
>
> $ apt-get source parted
> $ cd parted-2.2
> $ grep -rn "error message here" .
>
> -r makes search recursive, -n makes grep output line numbers next to the
> filenames. Then I opened a text editor on the file and line number that grep
> mentioned, and tried to figure out the code :)
Isn't trying to figure out why an arbitrary piece of code doesn't work
formally equivilent to the Halting Problem? (With non-termination simply
being the most basic kind of program bug...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What's CreateObject?
>
> It looks up names in the registry and translates them to 20-digit GUIDs.
See, you definitely know far more about COM than I do. I wasn't even
aware that there *are* names associated with GUIDs...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Invisible wrote:
>> 3. It really takes that much code just to do the same task as DIR /B C:\
>> C:\FileList.txt?
>
> Says the guy who would rather write his own program to do specific searches
> than figure out grep :)
Or rather, I'd rather write my own program than use grep for a *complex*
search. (E.g., find anything that's a valid XML fragment.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Or rather, I'd rather write my own program than use grep for a *complex*
> search. (E.g., find anything that's a valid XML fragment.)
Don't start making unfair comparisons. 'grep' (as well as other similar
tools such as 'sed') is a line-based tool. It can match individual *lines*
of the input. It cannot be used to perform operations which would require
interpreting several lines (unless it has some non-standard extensions).
Recognizing a valid XML fragment would require interpreting several lines
of the input (if you want to be able to match all possible cases), and hence
'grep' cannot be used for that.
'grep' is most useful for finding things you know are all in one line,
and for filtering files with a known format (such as httpd logs).
If you need more complicated things like that, then often 'awk' or 'perl'
can be used (still usually with shorter commands and faster than writing
your own program would). For example 'perl' can be used for the same things
as 'grep' and 'sed', but it has a vastly expanded set of match patterns and
other instructions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Or rather, I'd rather write my own program than use grep for a *complex*
>> search. (E.g., find anything that's a valid XML fragment.)
>
> Don't start making unfair comparisons. 'grep' (as well as other similar
> tools such as 'sed') is a line-based tool. It can match individual *lines*
> of the input. It cannot be used to perform operations which would require
> interpreting several lines (unless it has some non-standard extensions).
>
> Recognizing a valid XML fragment would require interpreting several lines
> of the input (if you want to be able to match all possible cases), and hence
> 'grep' cannot be used for that.
Right. And when I do text processing, this is the kind of task I usually
want to do. Which is perhaps why grep doesn't sound especially useful to me.
Still, if your goal is just to find out if (or where) a file contains a
particular word or code number, I agree that grep is probably the
fastest way to find it.
> 'grep' is most useful for finding things you know are all in one line,
> and for filtering files with a known format (such as httpd logs).
I gather line-based file formats are quite common in Unix. (E.g., fstab
is line-based, IIRC.) Such things are comparatively rare for Windows
though. About the closest thing is CSV files. But - as I recently
discovered - CSV isn't really line-based. (A single record can span
multiple lines. At least, according to the RFC.)
> If you need more complicated things like that, then often 'awk' or 'perl'
> can be used (still usually with shorter commands and faster than writing
> your own program would).
I would debate that, but let's not start another argument...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > If you need more complicated things like that, then often 'awk' or 'perl'
> > can be used (still usually with shorter commands and faster than writing
> > your own program would).
> I would debate that, but let's not start another argument...
Are you saying that you don't think one could write a significantly
shorter command using perl than with your favorite language? Maybe you
just don't know that perl can be used directly from the command line,
giving the "program" as an argument, and hence it can be used very much
like grep or sed. For example:
perl -pe 's|\d+|$&+1|ge' file.txt
This searches for any consecutive digits in 'file.txt', interprets them
as numbers and outputs the contents of the file but with each of these
numbers incremented by 1. (Thus if the file had a something like
"value = 123;" somewhere, the result would have "value = 124;" instead.)
I don't know Haskell too well, but I'm pretty certain it takes a bit
more code to do that (and additionally you probably can't just write the
code on the command line).
(And yes, I know that the string given to perl looks gibberish to you.
It's not gibberish when you understand what it means.)
Of course this is just a simple example. Perl can be used to make
significantly more complex substitutions (and other things) in a similar
way.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
