Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #66598 > unrolled thread

Useless Use Of Regexes

Back to article view | Back to comp.os.linux.misc

Contents

  Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 20:34 +0000
    Re: Useless Use Of Regexes Pancho <Pancho.Jones@protonmail.com> - 2025-03-24 21:48 +0000
      Re: Useless Use Of Regexes The Natural Philosopher <tnp@invalid.invalid> - 2025-03-24 22:57 +0000
      Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 22:59 +0000
        Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-25 08:30 +0100
          Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-26 00:35 +0000
            Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-26 08:20 +0100
        Re: Useless Use Of Regexes Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-03-25 11:09 +0200
          Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-25 13:03 +0100
            Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-26 00:42 +0000
              Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-26 08:21 +0100
                Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-26 19:45 +0000
                  Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-26 21:43 +0100
                    Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-26 23:50 +0000
                      Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-27 07:58 +0100
                        Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-27 07:25 +0000
                          Re: Useless Use Of Regexes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-27 16:51 +0100
                            Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-27 21:05 +0000
                              Re: Useless Use Of Regexes marrgol <marrgol@address.invalid> - 2025-03-28 12:21 +0100
                                Re: Useless Use Of Regexes Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-03-28 11:42 -0400
                                  Re: Useless Use Of Regexes rbowman <bowman@montana.com> - 2025-03-28 18:46 +0000
                                    Re: Useless Use Of Regexes Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-03-29 11:40 -0400
                                Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-28 20:25 +0000
                              Re: Useless Use Of Regexes Wayne <wayne@nospam.invalid> - 2025-03-31 23:54 -0400
                  Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-03-27 04:08 -0400
            Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-03-26 00:47 -0400
              Re: Useless Use Of Regexes rbowman <bowman@montana.com> - 2025-03-26 16:51 +0000
                Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-03-27 03:13 -0400
        Re: Useless Use Of Regexes Pancho <Pancho.Jones@protonmail.com> - 2025-03-25 12:08 +0000
      Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-03-30 14:04 +0000
    Re: Useless Use Of Regexes Ben Collver <bencollver@tilde.pink> - 2025-03-25 15:29 +0000
    Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-03-30 14:02 +0000
      Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-30 21:15 +0000
        Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-03-30 22:04 +0000
          Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-31 01:26 +0000
            Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-06 08:40 +0000
              Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-07 21:39 +0000
                Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-04-07 21:00 -0400
                Re: Useless Use Of Regexes Eli the Bearded <*@eli.users.panix.com> - 2025-04-08 02:05 +0000
                  Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-04-07 22:06 -0400
                  Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 05:49 +0000
                  Re: Useless Use Of Regexes Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-04-08 15:39 +0300
                    Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-09 01:16 +0000
                      Re: Useless Use Of Regexes c186282 <c186282@nnada.net> - 2025-04-08 22:32 -0400
                        Shell command history (was: Useless Use Of Regexes) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2025-04-09 13:26 +0100
                          Re: Shell command history (was: Useless Use Of Regexes) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 06:55 +0000
                            Re: Shell command history (was: Useless Use Of Regexes) Eli the Bearded <*@eli.users.panix.com> - 2025-04-12 23:55 +0000
                            Re: Shell command history Nuno Silva <nunojsilva@invalid.invalid> - 2025-04-14 09:47 +0100
                              Re: Shell command history Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 22:37 +0000
                                Re: Shell command history Eli the Bearded <*@eli.users.panix.com> - 2025-04-15 23:28 +0000
                                  Re: Shell command history Andreas Eder <a_eder_muc@web.de> - 2025-04-16 10:09 +0200
                                  Re: Shell command history Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-16 21:33 +0000
                                    Re: Shell command history Eli the Bearded <*@eli.users.panix.com> - 2025-04-18 04:22 +0000
                                      Re: Shell command history Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-19 22:34 +0000
                                        Re: Shell command history Eli the Bearded <*@eli.users.panix.com> - 2025-04-20 18:26 +0000
                                Re: Shell command history Nuno Silva <nunojsilva@invalid.invalid> - 2025-04-18 10:31 +0100
                      Re: Useless Use Of Regexes Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-04-09 10:53 +0300
                        Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 06:55 +0000
                  Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-12 13:07 +0000
                Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-12 11:23 +0000
                  Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-13 04:54 +0000
                    Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-13 18:25 +0000
                      Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 22:39 +0000
                        Re: Useless Use Of Regexes Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-04-17 19:44 +0000
                          Re: Useless Use Of Regexes Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-18 02:18 +0000
                    Re: Useless Use Of Regexes candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-13 19:00 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#66696

On Fri, 28 Mar 2025 11:42:37 -0400, Chris Ahlstrom wrote:

> The getopt family is a pain in the ass. I wrote my own command-line
> parsing,
> though I do not use it in legacy apps.

I've never used getopt_long() but I find getopt() to be cleaner than DIY 
parsing. 

[toc] | [prev] | [next] | [standalone]

#66728

rbowman wrote this post while blinking in Morse code:

> On Fri, 28 Mar 2025 11:42:37 -0400, Chris Ahlstrom wrote:
>
>> The getopt family is a pain in the ass. I wrote my own command-line
>> parsing,
>> though I do not use it in legacy apps.
>
> I've never used getopt_long() but I find getopt() to be cleaner than DIY 
> parsing. 

My parser accepts an array of option structures specifying the long name, the
character code (if any), the type of data represented by the option,
enabling/disabling of options, the default value, the current value,
a dirty flag, and a description.  It generates color-coded help. It has
common built-in options for help and verbosity, for example. And of
course a number of test apps.

Options can be grouped into sections suitable for read/write from an INI-style
file, complete with descriptions of each section.

It's written in C++, but with a C interface also provided.

During my recent wrestling with getopt_long(), I noticed a couple other
features to cover.  

I'm not claiming anyone other than I will ever want to use it :-)

-- 
The departing division general manager met a last time with his young
successor and gave him three envelopes.  "My predecessor did this for me,
and I'll pass the tradition along to you," he said.  "At the first sign
of trouble, open the first envelope.  Any further difficulties, open the
second envelope.  Then, if problems continue, open the third envelope.
Good luck."  The new manager returned to his office and tossed the envelopes
into a drawer.
	Six months later, costs soared and earnings plummeted. Shaken, the
young man opened the first envelope, which said, "Blame it all on me."
	The next day, he held a press conference and did just that.  The
crisis passed.
	Six months later, sales dropped precipitously.  The beleaguered
manager opened the second envelope.  It said, "Reorganize."
	He held another press conference, announcing that the division
would be restructured.  The crisis passed.
	A year later, everything went wrong at once and the manager was
blamed for all of it.  The harried executive closed his office door, sank
into his chair, and opened the third envelope.
	"Prepare three envelopes..." it said.

[toc] | [prev] | [next] | [standalone]

#66700

On Fri, 28 Mar 2025 12:21:20 +0100, marrgol wrote:

> On 2025-03-27 at 22:05 Lawrence D'Oliveiro wrote:
>>
>> On Thu, 27 Mar 2025 16:51:16 +0100, Marc Haber wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Thu, 27 Mar 2025 07:58:32 +0100, Marc Haber wrote:
>>>>>
>>>>> You could have it easier with getopt ...
>>>>
>>>> Last I checked, getopt doesn’t do long options.
>>>
>>> You should check again.
>> 
>> ldo@theon:~> help getopt getopts: getopts optstring name [arg ...]
>> […]
> 
> You're quoting help to 'getopts' shell built-in command --
> you are mistaking it for 'getopt' program from util-linux.

I had a look at that, too. Here’s an extract from the example script
/usr/share/doc/util-linux/examples/getopt-example.bash demonstrating
the use of the getopt(1) command from util-linux:

----
TEMP=$(getopt -o 'ab:c::' --long 'a-long,b-long:,c-long::' -n 'example.bash' -- "$@")

if [ $? -ne 0 ]; then
    echo 'Terminating...' >&2
    exit 1
fi

# Note the quotes around "$TEMP": they are essential!
eval set -- "$TEMP"
unset TEMP

while true; do
    case "$1" in
        '-a'|'--a-long')
            echo 'Option a'
            shift
            continue
        ;;
        '-b'|'--b-long')
            echo "Option b, argument '$2'"
            shift 2
            continue
        ;;
        '-c'|'--c-long')
            # c has an optional argument. As we are in quoted mode,
            # an empty parameter will be generated if its optional
            # argument is not found.
            case "$2" in
                '')
                    echo 'Option c, no argument'
                ;;
                *)
                    echo "Option c, argument '$2'"
                ;;
            esac
            shift 2
            continue
        ;;
        '--')
            shift
            break
        ;;
        *)
            echo 'Internal error!' >&2
            exit 1
        ;;
    esac
done
----

Doesn’t seem to me that’s saving much effort. Does it look like a
saving of effort to you?

[toc] | [prev] | [next] | [standalone]

#66769

On 3/27/2025 5:05 PM, Lawrence D'Oliveiro wrote:
> On Thu, 27 Mar 2025 16:51:16 +0100, Marc Haber wrote:
> 
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Thu, 27 Mar 2025 07:58:32 +0100, Marc Haber wrote:
>>>
>>>> You could have it easier with getopt ...
>>>
>>> Last I checked, getopt doesn’t do long options.
>>
>> You should check again.
> 
> ldo@theon:~> help getopt
> getopts: getopts optstring name [arg ...]
>      Parse option arguments.
> ...

Note that getopt is different from getopts!

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#66664

On 3/26/25 3:45 PM, Lawrence D'Oliveiro wrote:
> On Wed, 26 Mar 2025 08:21:42 +0100, Marc Haber wrote:
> 
>> It has become better since I usually start off with ChatGPT which
>> takes care of the boilerplate stuff.
> 
> The main point of using a very-high-level language (like bash) is that you
> shouldn’t need any boilerplate stuff.

   Bash is "high-level" ???   :-)

   Could write a near-clone in 'C' in a few lazy days.
   Gimme a week, ASM.

   Depends on defs I guess.

   As for "Chat" and friends ... just don't see myself
   EVER using them. Writing the 'boilerplate' is all part
   of the challenge, the FUN. 'AI' may have its weird
   little ideas, but to date humans can be much more
   creative.

[toc] | [prev] | [next] | [standalone]

#66630

On 3/25/25 8:03 AM, Marc Haber wrote:
> Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> Don’t forget the option of JSON-format output, for even easier processing
>>> in scripts than messing around with regexes.
>>
>> Kinda yes, but for a script I'd really like to just get the data
>> directly in an associative array that I can use as is. Instead of
>> messing around with jq. I just took a look around in Stack Exchange but
>> meh. One simplish bash example was this:
>>
>> typeset -A myarray
>>
>> while IFS== read -r key value; do
>>     myarray["$key"]="$value"
>> done < <(jq -r '.SITE_DATA | to_entries | .[] | .key + "=" + .value ' file.json)
>>
>> But that still pukes if the data happens to have a numeric value and in
>> ip route output at least the metric value is numeric. So apparently it
>> needs to become .key + "=" + (.value|tostring) to handle that.
> 
> This is a classic example why shellscripts are inferior. If you had
> written that in python, you could just ingest iproute's output in a
> python data structire and access it naturally.
> 
> A very wise German person, today a friend of mine, used to say 25
> years ago: "Verwende perl. Shell will man können, dann aber nicht
> verwenden." In English that would be "Use Perl. You want to be able to
> use Shell, but then don't use it." Today, of course, that would be
> python.

   ANYthing but Perl !!!   :-)

   Ok, except maybe Lisp ......

   It is popular to hate Python these days. Not sure
   why except that it's popular/common and, horrors !,
   even the NEWBIES can use it.

   I do still write bash scripts, IF the job is kinda
   simple and straight-forward. However getting 'fancy'
   stuff done in scripts soon becomes anything but
   transparent ... too many squiggles and punctuation
   chars in EXACTLY the right places - a lang extended
   and extended and extended kinda ad-hoc until it's
   easy to get an unreadable mess. Python is much
   easier and more self-documenting. These days it's
   even fairly fast. TONS of libraries and examples
   out there too.

   Today had to make a few mods to a 450-line Python
   pgm I wrote about three years ago. Was NOT hard,
   could follow what I'd writ before. That's not
   always the case with 'C' fer sure  :-)

   Anyway, generally proto everything in Python these
   days, fool around with everything because it's
   easy, and then if appropriate port it over to 'C'
   or Pascal (still love Pascal !).

   Hmmm ... one of the things that attracted me to
   the Unix side long long ago was the 'C-shell' ...
   yet for some reason I never DID anything with it.
   Perhaps time for a second look .....

   As for regex ... avoid whenever possible. WORSE
   syntax than Bash - gobbeldegoop. More plain to
   write a few easy lines of Python for the same
   effect ........

[toc] | [prev] | [next] | [standalone]

#66638

On Wed, 26 Mar 2025 00:47:11 -0400, c186282 wrote:

>    Hmmm ... one of the things that attracted me to the Unix side long
>    long ago was the 'C-shell' ...
>    yet for some reason I never DID anything with it.
>    Perhaps time for a second look .....

I used tcsh for years and even had a Windows version. I switched to bash 
reluctantly when it became the default on most Linux distros. It was 
annoying since I had a number of aliases that had to be rewritten as 
functions in .bashrc.  I saw that more as a bug than a feature.

[toc] | [prev] | [next] | [standalone]

#66658

On 3/26/25 12:51 PM, rbowman wrote:
> On Wed, 26 Mar 2025 00:47:11 -0400, c186282 wrote:
> 
>>     Hmmm ... one of the things that attracted me to the Unix side long
>>     long ago was the 'C-shell' ...
>>     yet for some reason I never DID anything with it.
>>     Perhaps time for a second look .....
> 
> I used tcsh for years and even had a Windows version. I switched to bash
> reluctantly when it became the default on most Linux distros. It was
> annoying since I had a number of aliases that had to be rewritten as
> functions in .bashrc.  I saw that more as a bug than a feature.

   Well, they were never made to be "the same" ....

   LOOKED for good stuff oh csh/tcsh yesterday and
   surprisingly not MUCH useful stuff/examples to
   be found - at least in the first page or two of
   search results. As such I'd say it's become rather
   "unpopular" ... though not necessarily bad or
   incapable.

   A much more 'C-ish' shell DOES appeal to me. DID
   also come across a utility that proports to turn
   Bash scrips INTO executable 'C' ... gotta fool
   with that for awhile. However initially writing
   in something more like 'C' is where the appeal
   lies.

   Found, ran, a few simple csh examples ... all
   good. But, gotta see how to EXPAND those.

   TODAY'S job ... wanna move my existing MX install
   on a BMax unit to my newer BeeLink N150 unit so
   I can use the extra CPU to combine two boxes
   into one. Now, HOW does fuckin' WORM set static
   IP addresses ..... I posted on that a year or so
   ago .......... they should have stuck to /etc/
   networking like all the historical examples ....

   MX does include a 'clone' utility - sparse
   backup that will produce an installable ISO.

   I've used it before and it WORKS. That's my
   path - minimal work afterwards. N95 Gen 12 to
   N150 Gen-13 should give the extra oomph to
   combine what I've needed two N95 boxes to do.

   New board still has 16gb, but a 1tb M.2 SSD
   for under $200us. Figured I'd better buy NOW
   as the Trump tariffs are gonna screw things
   up pretty bad for awhile.

   The old N95s ... I'll think of something ...
   wanted to add a few more security cams/sensors
   in out-buildings ....... 'Motion', note recent
   config revisions ... does just great at
   turning cam snapshots into handy mjpeg streams.

   Just, for PRIDE, gotta make sure the included
   Winders on new box doesn't run for a microsecond  :-)

   Um ... may be wrong ... but it seems BeeLink
   includes FOUR USB3 ports but BMax only TWO.

   Just for info, don't know if anyone cares, finding
   small IR-capable USB cams is a PAIN IN THE ASS these
   days. Was working off a small stock of 'Spinel' units -
   in a very small thin minimalist box with threads
   for M12 lenses. Now they stopped making those.

   "ArduCams" sold on Amazon LOOK kinda the same,
   but the motherfuckers stick an IR filter right
   on the sensor chip ! Managed to tease two of
   those off - but ruined the 3rd cam. Even finding
   IR unfiltered lenses is a trial - SOMETIMES can
   break off the filter, sometimes not. Why the hell
   do they DO that ???

   If you don't want IR there's NO issue finding
   filtered lenses ! I've got a old fairly big
   property and have IR floods to illuminate - 250'
   to road/mailbox. DO have a couple of 600 series
   HP webcams I destroyed, glued M12 sockets to,
   good for IR now and you can even get audio. Newer
   models have the damned IR filter glued-on. 'Real'
   canned IP cams ARE fairly cheap now - some under
   $100usd. 1080p is good enough. However they're
   just not as FUN as do-it-yourself.

   So interesting ... in IR spectrum ... black
   clothing oft looks red, even white ... the
   dyes are intended for human-spectrum only.
   Have ONE cam with a 1500nm filter, deeper IR.
   Things look even more interesting.

   Oh well, I've rambled on .........

   Party on dude !

[toc] | [prev] | [next] | [standalone]

#66614

On 3/24/25 22:59, Lawrence D'Oliveiro wrote:
> On Mon, 24 Mar 2025 21:48:26 +0000, Pancho wrote:
> 
>> On 3/24/25 20:34, Lawrence D'Oliveiro wrote:
>>
>>> which can be more easily written using features built into iproute2
>>> itself:
>>>
>>>       ip addr show to 192.168.1.0/24
>>
>> Seriously, though, it is often easier to filter output from a standard
>> command with grep, than it is to learn all the command flags.
> 
> Don’t forget the option of JSON-format output, for even easier processing
> in scripts than messing around with regexes.

Forget? That presumes I ever knew. Well maybe I did, nowadays, I forget 
what I have forgotten.

Anyway, JSON output looks cool. However, it doesn't seem to be common 
for other commands.

[toc] | [prev] | [next] | [standalone]

#66739

Le 24-03-2025, Pancho <Pancho.Jones@protonmail.com> a écrit :
>
> Seriously, though, it is often easier to filter output from a standard 
> command with grep, than it is to learn all the command flags.

Yes, mostly when you want to find something by creating your request
depending on its results.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#66618

On 2025-03-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> namely this one:
>
>     ip addr | grep -Eo '192\.168\.1\.[0-9]{1,3}'
>
> which can be more easily written using features built into iproute2 itself:
>
>     ip addr show to 192.168.1.0/24

Even if you were going to use regex for that, since the mask is /24,
why not shorten it?

OLD: ip addr | grep -Eo '192\.168\.1\.[0-9]{1,3}'
NEW: ip addr | grep -Eo '192\.168\.1\.'

[toc] | [prev] | [next] | [standalone]

#66738

Le 24-03-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
> Besides the traditional “Useless Use Of Cat” (UUOC) newbie faux pas,

The UUOC is more a claim made by FR/DG/LP/whatever and the like than a
really newbie issue. It's a good and easy way to look at what you do
before removing the cat and redirecting the output to another program.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#66746

On 30 Mar 2025 14:02:51 GMT, Stéphane CARPENTIER wrote:

> The UUOC is more a claim made by FR/DG/LP/whatever and the like than a
> really newbie issue. It's a good and easy way to look at what you do
> before removing the cat and redirecting the output to another program.

You can look at the output without a cat. That’s the whole point about it 
being useless.

[toc] | [prev] | [next] | [standalone]

#66747

Le 30-03-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
> On 30 Mar 2025 14:02:51 GMT, Stéphane CARPENTIER wrote:
>
>> The UUOC is more a claim made by FR/DG/LP/whatever and the like than a
>> really newbie issue. It's a good and easy way to look at what you do
>> before removing the cat and redirecting the output to another program.
>
> You can look at the output without a cat. 

Yes, with the right option and/or with the right modification of the
command line. But it's easier and faster to just add a cat than to find
the "right" way to do it.

> That’s the whole point about it being useless.

On a modern computer, the time taken to avoid using cat is far more
important than the time taken by the computer to provide the result. So,
if you want a fast result, you don't care about UUOC and you just add a
cat when you want. It's the whole point about stopping the pedantic
speaking about UUOC. Because it's not useless: it provides an easy and
fast way to get what you want.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#66749

On 30 Mar 2025 22:04:45 GMT, Stéphane CARPENTIER wrote:

> Yes, with the right option and/or with the right modification of the
> command line. But it's easier and faster to just add a cat than to find
> the "right" way to do it.

Give an example.

[toc] | [prev] | [next] | [standalone]

#66951

Le 31-03-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
> On 30 Mar 2025 22:04:45 GMT, Stéphane CARPENTIER wrote:
>
>> Yes, with the right option and/or with the right modification of the
>> command line. But it's easier and faster to just add a cat than to find
>> the "right" way to do it.
>
> Give an example.

A lot of time I run cat to find some information in a file. And when the
file is bigger than expected, I'll just grep its output. Of course,
it's better to directly grep the file, but it's easier and faster to add
a grep at the end of the previous command than to either write directly
the right command or to go at the beginning of the line to remove the
cat and put grep instead. Mostly when the name of the file is long in a
far remote directory.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#67012

On 06 Apr 2025 08:40:54 GMT, Stéphane CARPENTIER wrote:

> Le 31-03-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
>
>> On 30 Mar 2025 22:04:45 GMT, Stéphane CARPENTIER wrote:
>>
>>> Yes, with the right option and/or with the right modification of the
>>> command line. But it's easier and faster to just add a cat than to
>>> find the "right" way to do it.
>>
>> Give an example.
> 
> A lot of time I run cat to find some information in a file. And when the
> file is bigger than expected, I'll just grep its output. Of course,
> it's better to directly grep the file, but it's easier and faster to add
> a grep at the end of the previous command than to either write directly
> the right command or to go at the beginning of the line to remove the
> cat and put grep instead. Mostly when the name of the file is long in a
> far remote directory.

You do have command-line editing enabled, right? You just press the HOME 
key (or CTRL/A) to go to the start of the line.

[toc] | [prev] | [next] | [standalone]

#67017

On 4/7/25 5:39 PM, Lawrence D'Oliveiro wrote:
> On 06 Apr 2025 08:40:54 GMT, Stéphane CARPENTIER wrote:
> 
>> Le 31-03-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
>>
>>> On 30 Mar 2025 22:04:45 GMT, Stéphane CARPENTIER wrote:
>>>
>>>> Yes, with the right option and/or with the right modification of the
>>>> command line. But it's easier and faster to just add a cat than to
>>>> find the "right" way to do it.
>>>
>>> Give an example.
>>
>> A lot of time I run cat to find some information in a file. And when the
>> file is bigger than expected, I'll just grep its output. Of course,
>> it's better to directly grep the file, but it's easier and faster to add
>> a grep at the end of the previous command than to either write directly
>> the right command or to go at the beginning of the line to remove the
>> cat and put grep instead. Mostly when the name of the file is long in a
>> far remote directory.
> 
> You do have command-line editing enabled, right? You just press the HOME
> key (or CTRL/A) to go to the start of the line.


   That works OK. However 'grep' tends to be THE most
   valuable utility for finding what you want in a
   vast sea of files.

[toc] | [prev] | [next] | [standalone]

#67019

In comp.os.linux.misc, Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:
> On 06 Apr 2025 08:40:54 GMT, Stéphane CARPENTIER wrote:
>> A lot of time I run cat to find some information in a file. And when the
>> file is bigger than expected, I'll just grep its output. Of course,
>> it's better to directly grep the file, but it's easier and faster to add
>> a grep at the end of the previous command than to either write directly
>> the right command or to go at the beginning of the line to remove the
>> cat and put grep instead. Mostly when the name of the file is long in a
>> far remote directory.
> You do have command-line editing enabled, right? You just press the HOME 
> key (or CTRL/A) to go to the start of the line.

Very presumptious to assume emacs style line editing, isn't it?

To go back in history, I type <ESC>k and then I'm at the start of the
line of the most recent command. On the current line I'd type <ESC>^
but <ESC><HOME> would work.

But really, I don't think it is proper to care about inefficent use of
commands at the command line. Go ahead and judge in a script or
documentation (or an example posted to Usenet), but what people do in
the privacy of their own shell is their business.

Elijah
------
uses <HOME>/<END> pretty much exclusively in GUI tools like browsers

[toc] | [prev] | [next] | [standalone]

#67020

On 4/7/25 10:05 PM, Eli the Bearded wrote:
> In comp.os.linux.misc, Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:
>> On 06 Apr 2025 08:40:54 GMT, Stéphane CARPENTIER wrote:
>>> A lot of time I run cat to find some information in a file. And when the
>>> file is bigger than expected, I'll just grep its output. Of course,
>>> it's better to directly grep the file, but it's easier and faster to add
>>> a grep at the end of the previous command than to either write directly
>>> the right command or to go at the beginning of the line to remove the
>>> cat and put grep instead. Mostly when the name of the file is long in a
>>> far remote directory.
>> You do have command-line editing enabled, right? You just press the HOME
>> key (or CTRL/A) to go to the start of the line.
> 
> Very presumptious to assume emacs style line editing, isn't it?
> 
> To go back in history, I type <ESC>k and then I'm at the start of the
> line of the most recent command. On the current line I'd type <ESC>^
> but <ESC><HOME> would work.
> 
> But really, I don't think it is proper to care about inefficent use of
> commands at the command line. Go ahead and judge in a script or
> documentation (or an example posted to Usenet), but what people do in
> the privacy of their own shell is their business.

   Just use nano ....

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web