Besides the traditional “Useless Use Of Cat” (UUOC) newbie faux pas,
we can add “Useless Use Of Regexes”.
These can often be quite subtle. I spotted one obvious instance here <https://www.zdnet.com/article/5-ways-i-use-regex-in-linux-and-why-theyre-so-essential/>,
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
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.
Solve a problem with a RegEx, now you have two problems 🙂+1 LOL
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.
Don’t forget the option of JSON-format output, for even easier processing in scripts than messing around with regexes.
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.
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.
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
I'd prefer a regexp over jq any time. But that's probably wrong.
N.B.: ip addr --oneline
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.
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.
There is a certain challenge in seeing how far you can push things in
a shell script (or specifically, a bash script), before giving up and >switching to Python.
On Tue, 25 Mar 2025 08:30:56 +0100, Marc Haber wrote:
N.B.: ip addr --oneline
root@theon:~ # ip addr --oneline
Command "--oneline" is unknown, try "ip address help".
root@theon:~ # ip addr show --oneline
Device "--oneline" does not exist.
root@theon:~ # ip --oneline addr show
[got it]
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 .....
It has become better since I usually start off with ChatGPT which
takes care of the boilerplate stuff.
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.
Lawrence D'Oliveiro <ldo@nz.invalid> 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.
As soon as you make it flexlbie, with command line options, you begin
typing getopt or GetOptions stuff and that's pretty much boilerplate.
On Wed, 26 Mar 2025 21:43:51 +0100, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> 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.
As soon as you make it flexlbie, with command line options, you begin
typing getopt or GetOptions stuff and that's pretty much boilerplate.
Well, I do do that. Mainly it’s just a loop, though, e.g.
for ((;;)); do
if [ "${1:0:2}" != "--" ]; then
break
fi
if [ "$1" == "--" ]; then
shift
break
fi
opt="${1:2:${#1}}"
shift
val="${opt#*=}"
if [ "$val" = "$opt" ]; then
val=""
fi
opt="${opt%%=*}"
if [ "$opt" = "animation" ]; then
animation=1
elif [ "$opt" = "blender" ]; then
blender="$val"
elif [ "$opt" = "camera" ]; then
camera="$val"
elif [ "$opt" = "collections" ]; then
collections="$val"
elif [ "$opt" = "crash-protect" ]; then
crash_protect=1
elif [ "$opt" = "crash-retry-count" ]; then
crash_retry_count="$val"
elif [ "$opt" = "digits" ]; then
digits="$val"
...
else
opterror "bad option $opt"
fi
done
I would say, only a few lines in there count as “boilerplate” ...
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.
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.
You could have it easier with getopt ...
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.
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.
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 ...]
[…]
On 2025-03-27 at 22:05 Lawrence D'Oliveiro 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.
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.
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.
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.
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.
Seriously, though, it is often easier to filter output from a standard command with grep, than it is to learn all the command flags.
Besides the traditional “Useless Use Of Cat” (UUOC) newbie faux pas,
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.
...
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.
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.
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.
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.
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.
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 theYou do have command-line editing enabled, right? You just press the HOME
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.
key (or CTRL/A) to go to the start of the line.
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,You do have command-line editing enabled, right? You just press the HOME
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.
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.
Very presumptious to assume emacs style line editing, isn't it?
But really, I don't think it is proper to care about inefficent use of commands at the command 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.
The only time I've had to use vi command history editing was with some
old version of VxWorks. It was the only kind included by default. I
ended up teaching some colleagues on how to edit the command line, vi
style.
On Tue, 08 Apr 2025 15:39:47 +0300, Anssi Saari wrote:
The only time I've had to use vi command history editing was with some
old version of VxWorks. It was the only kind included by default. I
ended up teaching some colleagues on how to edit the command line, vi
style.
Seems a bit dumb, having to go into insert mode every time you actually
want to type a command.
Seems a bit dumb, having to go into insert mode every time you actually
want to type a command.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Seems a bit dumb, having to go into insert mode every time you actually
want to type a command.
Sure. Still, way better than no command history at all.
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.
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,You do have command-line editing enabled, right? You just press the HOME
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.
key (or CTRL/A) to go to the start of the line.
Very presumptious to assume emacs style line editing, isn't it?
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.
Yes. And then, I have to remove "cat". And only then can I write "grep". Which is more difficult than just writing "| grep" at the end of the
line.
On 12 Apr 2025 11:23:14 GMT, Stéphane CARPENTIER wrote:
Yes. And then, I have to remove "cat". And only then can I write "grep".
Which is more difficult than just writing "| grep" at the end of the
line.
Let’s see:
* CTRL/A, DEL, DEL, DEL, “grep” (8 keystrokes)
versus
* “|grep” (5 keystrokes)
That’s 60% more work. I suppose that’s a big chunk out of your working day ...
On 12 Apr 2025 11:23:14 GMT, Stéphane CARPENTIER wrote:
Yes. And then, I have to remove "cat". And only then can I write "grep".
Which is more difficult than just writing "| grep" at the end of the
line.
Let’s see:
* CTRL/A, DEL, DEL, DEL, “grep” (8 keystrokes)
versus
* “|grep” (5 keystrokes)
That’s 60% more work. I suppose that’s a big chunk out of your working day ...
Here’s an even more useless example:
cat «file» | grep «pattern» | wc -l
versus
grep -c «pattern» «file»
So why do you want to fight the UUOC?
Why should I follow your advice?
On 13 Apr 2025 18:25:56 GMT, Stéphane CARPENTIER wrote:
So why do you want to fight the UUOC?
I don’t.
Why should I follow your advice?
You don’t.
All I do is point it out. I don’t even have to say “this is uncool”, you
yourself come to the conclusion that they are somehow an uncool way of
doing things.
Le 14-04-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
On 13 Apr 2025 18:25:56 GMT, Stéphane CARPENTIER wrote:
So why do you want to fight the UUOC?
I don’t.
Why should I follow your advice?
You don’t.
All I do is point it out. I don’t even have to say “this is uncool”, you
yourself come to the conclusion that they are somehow an uncool way of
doing things.
The name UUOC, by itself, means it's uncool to do it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 103:26:26 |
| Calls: | 9,684 |
| Calls today: | 5 |
| Files: | 13,725 |
| Messages: | 6,175,093 |
| Posted today: | 1 |