<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find” command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of finding something I might have worked on years ago, and mostly forgotten about
since then.
On Wed, 13 Aug 2025 01:16:20 -0000 (UTC), Lawrence D'Oliveiro wrote:
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find”
command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of finding
something I might have worked on years ago, and mostly forgotten about
since then.
It's very annoying when I have a senior moment and try to use find on a Windows box. While I have ls, grep, cat, and so forth 'find' finds the
lame Windows command. I suppose I should fix that.
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find” command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
(Which is a lot of things.)
Strange list.
1. rm
2. mv
3. cp
4. ls
5. find
6. locate (because you're not running "find" on /, are you?)
Should the list continue,
7. pkill/pgrep
8. grep
9. apropos
10. ip
Strange list.
1. rm
2. mv
3. cp
4. ls
5. find
6. locate (because you're not running "find" on /, are you?)
Should the list continue,
7. pkill/pgrep
8. grep
9. apropos
10. ip
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find” command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
(Which is a lot of things.)
Strange list.
1. rm 2. mv 3. cp 4. ls 5. find 6. locate (because you're not running
"find" on /, are you?)
Should the list continue,
7. pkill/pgrep 8. grep 9. apropos 10. ip
Strange list.
1. rm
2. mv
3. cp
4. ls
5. find
6. locate (because you're not running "find" on /, are you?)
Should the list continue,
7. pkill/pgrep
8. grep
9. apropos
10. ip
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/><snip>
What?s an obvious omission from his list? To me, it?s the ?find?
command. I have millions of files on my main machine (quite literally,
With the command chmod u+x filename....
2. lsbci
3. lsblk
5 ps
6 grep
8. service
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands?
Mine is "ls -ltr", which shows files in chronological order.
Often I'm looking for a file I worked on recently but can't
remember its exact name; it shows up near the end of an
ls -ltr list.
Or drop the “r” and have it show up near the top.
How about a list of favourite options to common commands?
Mine is "ls -ltr", which shows files in chronological order.
Often I'm looking for a file I worked on recently but can't
remember its exact name; it shows up near the end of an
ls -ltr list.
On 2025-08-13 23:31, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands? Mine is
"ls -ltr", which shows files in chronological order. Often I'm
looking for a file I worked on recently but can't remember its
exact name; it shows up near the end of an ls -ltr list.
Or drop the “r” and have it show up near the top.
The top is out of the screen and not visible.
Lawrence D'Oliveiro wrote this post while blinking in Morse code:
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find”
command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
(Which is a lot of things.)
I use the cdb command from the cdargs package alla time.
And a lotta other command-line commands mapped to keystrokes.
But enough about me.
On Wed, 13 Aug 2025 23:40:20 +0200, Carlos E. R. wrote:
On 2025-08-13 23:31, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands? Mine is "ls
-ltr", which shows files in chronological order. Often I'm looking
for a file I worked on recently but can't remember its exact name; it
shows up near the end of an ls -ltr list.
Or drop the “r” and have it show up near the top.
The top is out of the screen and not visible.
*nix user 101: figure out at least 3 simple (i.e. routine)
command-line techniques for dealing with that.
How about a list of favourite options to common commands? Mine is "ls
-ltr", which shows files in chronological order.
Often I'm looking for a file I worked on recently but can't remember its exact name; it shows up near the end of an ls -ltr list.
- emacs (but this one is going to be quite subjective)
On 2025-08-13 23:31, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands?
Mine is "ls -ltr", which shows files in chronological order.
Often I'm looking for a file I worked on recently but can't
remember its exact name; it shows up near the end of an
ls -ltr list.
Or drop the “r” and have it show up near the top.
The top is out of the screen and not visible.
On Wed, 13 Aug 2025 23:40:20 +0200, Carlos E. R. wrote:
On 2025-08-13 23:31, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands? Mine is
"ls -ltr", which shows files in chronological order. Often I'm
looking for a file I worked on recently but can't remember its
exact name; it shows up near the end of an ls -ltr list.
Or drop the “r” and have it show up near the top.
The top is out of the screen and not visible.
*nix user 101: figure out at least 3 simple (i.e. routine)
command-line techniques for dealing with that.
On 2025-08-14 01:42, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 23:40:20 +0200, Carlos E. R. wrote:
On 2025-08-13 23:31, Lawrence D'Oliveiro wrote:
On Wed, 13 Aug 2025 19:34:11 GMT, Charlie Gibbs wrote:
How about a list of favourite options to common commands? Mine
is "ls -ltr", which shows files in chronological order. Often
I'm looking for a file I worked on recently but can't remember
its exact name; it shows up near the end of an ls -ltr list.
Or drop the “r” and have it show up near the top.
The top is out of the screen and not visible.
*nix user 101: figure out at least 3 simple (i.e. routine)
command-line techniques for dealing with that.
And so more typing.
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find” command.
On Wed, 13 Aug 2025 01:16:20 -0000 (UTC), Lawrence D'Oliveiro wrote:
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6- >commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find”
command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of finding
something I might have worked on years ago, and mostly forgotten about
since then.
It's very annoying when I have a senior moment and try to use find on a >Windows box. While I have ls, grep, cat, and so forth 'find' finds the
lame Windows command. I suppose I should fix that.
What’s an obvious omission from his list? To me, it’s the “find” >command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
(Which is a lot of things.)
Lawrence D'Oliveiro <[email protected]d> writes:
What’s an obvious omission from his list? To me, it’s the “find”
command.
Possibly or something like it. I just started looking into rawhide which
is another search tool. My interest is rawhide's ability to search for
tags in extended attributes. I've started adding tags to videos and
photos so I can search for those with rawhide.
On 2025-08-13, Lawrence D'Oliveiro <[email protected]d> wrote:[...]
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
zip
unzip
rsync
diff
cmp
cut
uniq
Favourite one-liner:
grep foo * | cut -d: -f1 | uniq
Charlie Gibbs <[email protected]d> wrote:
Favourite one-liner:
grep foo * | cut -d: -f1 | uniq
Why not 'grep -l foo *'?
On 13/08/2025 03:40, rbowman wrote:
On Wed, 13 Aug 2025 01:16:20 -0000 (UTC), Lawrence D'Oliveiro wrote:
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6- >>commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find” >>> command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
It's very annoying when I have a senior moment and try to use find on a >>Windows box. While I have ls, grep, cat, and so forth 'find' finds the
lame Windows command. I suppose I should fix that.
Some of the PowerShell equivalents of basic Unix commands are
hilariously
long winded.
On 15 Aug 2025 08:37:40 GMT
rbowman <[email protected]> wrote:
My use of PowerShell has mostly been a cut'n'paste of long, arcane
commands that I had no idea how they worked.
The funny part is that the commands and options are incredibly verbose
to the point where it's fairly straightforward to figure them out...
...except that actually discovering what the commands *are* (and which esoteric namespace you have to import to use them) is a quest worthy of Mallory or Tolkien and involves slogging through a morass of Spiceworks threads and defunct MSDN links with the aid of a search engine and/or
the Internet Archive :/
On 2025-08-15, John Ames <[email protected]> wrote:
The funny part is that the commands and options are incredibly verbose
to the point where it's fairly straightforward to figure them out...
Omigod, they've re-invented COBOL!
...except that actually discovering what the commands *are* (and which
esoteric namespace you have to import to use them) is a quest worthy of
Mallory or Tolkien and involves slogging through a morass of Spiceworks
threads and defunct MSDN links with the aid of a search engine and/or
the Internet Archive :/
I knew I could count on M$ to screw it up. Yet again.
On Thu, 14 Aug 2025 14:50:06 +0300, Anssi Saari wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
What’s an obvious omission from his list? To me, it’s the “find” >>> command.
Possibly or something like it. I just started looking into rawhide which
is another search tool. My interest is rawhide's ability to search for
tags in extended attributes. I've started adding tags to videos and
photos so I can search for those with rawhide.
The “find” command has the ability to execute external commands. Those can
produce output on their own, and/or their success/failure exit status can
be used as a filter on matching files.
On Fri, 15 Aug 2025 18:26:49 GMT, Charlie Gibbs wrote:
On 2025-08-15, John Ames <[email protected]> wrote:
The funny part is that the commands and options are incredibly verbose
to the point where it's fairly straightforward to figure them out...
Omigod, they've re-invented COBOL!
...except that actually discovering what the commands *are* (and which
esoteric namespace you have to import to use them) is a quest worthy of
Mallory or Tolkien and involves slogging through a morass of Spiceworks
threads and defunct MSDN links with the aid of a search engine and/or
the Internet Archive :/
I knew I could count on M$ to screw it up. Yet again.
Microsoft spent years, decades, conditioning its users to be allergic to
the command line. Now it has done a complete 180°, and is trying to make Windows more like Linux.
Trouble is, PowerShell is not exactly an improvement on what has gone
before.
Microsoft has also spent years, decades, conditioning its
users to accept crappy results.
Lawrence D'Oliveiro <[email protected]d> wrote at 22:45 this Thursday (GMT):
The “find” command has the ability to execute external commands.
Those can produce output on their own, and/or their success/failure
exit status can be used as a filter on matching files.
To be fair, "find" can be a bit of a rabbithole to learn.
On 2025-08-13 17:01, jayjwa wrote:
Strange list.
1. rm
2. mv
3. cp
4. ls
5. find
6. locate (because you're not running "find" on /, are you?)
Should the list continue,
7. pkill/pgrep
8. grep
9. apropos
10. ip
less, which is more than more.
man / info
Le 13-08-2025, Carlos E. R. <[email protected]d> a écrit :
less, which is more than more.
And most is at the same time more than less and more.
On 2025-08-13, Lawrence D'Oliveiro <[email protected]d> wrote:
<https://www.zdnet.com/article/im-a-linux-expert-and-here-are-6-commands-i-cant-live-without/>
What’s an obvious omission from his list? To me, it’s the “find”
command. I have millions of files on my main machine (quite literally,
I would say), and it is the most convenient and powerful way of
finding something I might have worked on years ago, and mostly
forgotten about since then.
(Which is a lot of things.)
zip
unzip
rsync
diff
cmp
cut
uniq
Favourite one-liner:
grep foo * | cut -d: -f1 | uniq
How about a list of favourite options to common commands?
Mine is "ls -ltr", which shows files in chronological order.
Often I'm looking for a file I worked on recently but can't
remember its exact name; it shows up near the end of an
ls -ltr list.
To be fair, "find" can be a bit of a rabbithole to learn. I personally
only know the basics of -name, -iname, and -type.
I've used Vim for years, have the Vim book, and know I use about 1% of its capabilities. If I stray from my trails, like trying to show line numbers,
I have to look it up. I know I can do a horizontal split but I only do vertical splits so I'd have to look that up too.
I never use "diff". I really don't like the way it's displayed. I'm using "vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using
"vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
The unified output (-u option) provides a 'diff' view that is much more ameniable to being understood by humans.
There are probably some command-line options and scripting which
would do it, but it was faster for me to cobble together some C code.
On 2025-08-16, Rich <[email protected]d> wrote:
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using >>> "vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
The unified output (-u option) provides a 'diff' view that is much more
ameniable to being understood by humans.
Horses for courses. I can read the standard diff output just fine.
Whether I qualify as "human" is open to discussion.
I wrote a little program called "cmpdir" which compares the contents
of two directories by doing an ls -lR on both of them (or dir /s in
the MS-DOS/Windows version), diffing them, and printing the significant differences, interspersed with lines indicating which directory they're
in. There are probably some command-line options and scripting which
would do it, but it was faster for me to cobble together some C code.
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using
"vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
On 2025-08-16, Rich <[email protected]d> wrote:
The unified output (-u option) provides a 'diff' view that is much
more ameniable to being understood by humans.
I'm not impressed by the difference.
(Although agreed that neither are sensible options for human
consumption.)
On 2025-08-16, rbowman <[email protected]> wrote:
I've used Vim for years, have the Vim book, and know I use about 1%
of its capabilities. If I stray from my trails, like trying to show
line numbers, I have to look it up. I know I can do a horizontal
split but I only do vertical splits so I'd have to look that up
too.
Occasionally I'll find I have enough use for something to take the
time to learn it. My most recent one with vim is /\<foo\>, which
finds "foo" only if it's an entire word (like grep's -w option).
On Sat, 16 Aug 2025 17:04:33 GMT, Charlie Gibbs wrote:
On 2025-08-16, rbowman <[email protected]> wrote:
I've used Vim for years, have the Vim book, and know I use about 1%
of its capabilities. If I stray from my trails, like trying to show
line numbers, I have to look it up. I know I can do a horizontal split
but I only do vertical splits so I'd have to look that up too.
Occasionally I'll find I have enough use for something to take the time
to learn it. My most recent one with vim is /\<foo\>, which finds "foo"
only if it's an entire word (like grep's -w option).
Vim is to text editors what PHP is to programming languages.
On 2025-08-16, rbowman <[email protected]> wrote:
I've used Vim for years, have the Vim book, and know I use about 1% of
its capabilities. If I stray from my trails, like trying to show line
numbers,
I have to look it up. I know I can do a horizontal split but I only do
vertical splits so I'd have to look that up too.
Occasionally I'll find I have enough use for something to take the time
to learn it. My most recent one with vim is /\<foo\>, which finds "foo"
only if it's an entire word (like grep's -w option).
On Sat, 16 Aug 2025 22:27:02 +0100, Richard Kettlewell wrote:
(Although agreed that neither are sensible options for human
consumption.)
I remember many decades ago one or two open-source projects specifying
that they wanted patches supplied in context-diff format. Nowadays unified-diff is just about universal.
I had to recheck “info diff” (the man page being insufficient in this case) to refresh my memory of what context-diff looked like; I would agree with the vast majority of open-source software developers, that unified-
diff is preferable.
On 16 Aug 2025 20:38:51 GMT, Stéphane CARPENTIER wrote:
On 2025-08-16, Rich <[email protected]d> wrote:
The unified output (-u option) provides a 'diff' view that is much
more ameniable to being understood by humans.
I'm not impressed by the difference.
By displaying the common lines just once, as surrounding context, the “-u”
format provides cues so a tool like patch(1) can find the place in the
file to substitute the old lines with the new ones. Not relying on strict line numbers to find the place is the secret to how patch is (usually)
able to do its work on a file that already has patches applied from other sources.
This facility for merging patches from multiple sources is the foundation
on which open-source development collaboration is built.
On 16 Aug 2025 20:38:51 GMT, Stéphane CARPENTIER wrote:
On 2025-08-16, Rich <[email protected]d> wrote:
The unified output (-u option) provides a 'diff' view that is much
more ameniable to being understood by humans.
I'm not impressed by the difference.
By displaying the common lines just once, as surrounding context, the “-u”
format provides cues so a tool like patch(1) can find the place in the
file to substitute the old lines with the new ones. Not relying on strict line numbers to find the place is the secret to how patch is (usually)
able to do its work on a file that already has patches applied from other sources.
This facility for merging patches from multiple sources is the foundation
on which open-source development collaboration is built.
Le 17-08-2025, Lawrence D’Oliveiro <[email protected]d> a écrit :
On 16 Aug 2025 20:38:51 GMT, Stéphane CARPENTIER wrote:
On 2025-08-16, Rich <[email protected]d> wrote:
The unified output (-u option) provides a 'diff' view that is
much more ameniable to being understood by humans.
I'm not impressed by the difference.
By displaying the common lines just once, as surrounding context,
the “-u” format provides cues so a tool like patch(1) can find the
place in the file to substitute the old lines with the new ones.
Not relying on strict line numbers to find the place is the secret
to how patch is (usually) able to do its work on a file that
already has patches applied from other sources.
I know what the differences are and what they are for. I mean, It's
far from enough to make me switch from vimdiff/nvim -d to diff.
This facility for merging patches from multiple sources is the
foundation on which open-source development collaboration is built.
I'm speaking about reading the output. Of course, long ago, sending
only patches like that was the easier way. Now, with git, it's done
behind the hood.
BTW, is it just lack of coffee or both the online manual page and the
GNU info manual section for GNU diff do not explain/specify the default output format? (Compare with IEEE 1003.1 [1].)
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/diff.html
On Sun, 17 Aug 2025 00:44:26 -0000 (UTC), Lawrence D’Oliveiro wrote:
I had to recheck “info diff” (the man page being insufficient inThe man page is little more than an option summary. The texinfo
this case) to refresh my memory of what context-diff looked like; I
would agree with the vast majority of open-source software
developers, that unified-diff is preferable.
manual describes the default output format here:
https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Normal.html
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using
"vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
The unified output (-u option) provides a 'diff' view that is much more ameniable to being understood by humans.
Lawrence D'Oliveiro <[email protected]d> wrote at 22:45 this Thursday (GMT):
On Thu, 14 Aug 2025 14:50:06 +0300, Anssi Saari wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
What’s an obvious omission from his list? To me, it’s the “find” >>>> command.
Possibly or something like it. I just started looking into rawhide which >>> is another search tool. My interest is rawhide's ability to search for
tags in extended attributes. I've started adding tags to videos and
photos so I can search for those with rawhide.
The “find” command has the ability to execute external commands. Those can
produce output on their own, and/or their success/failure exit status can
be used as a filter on matching files.
To be fair, "find" can be a bit of a rabbithole to learn. I personally
only know the basics of -name, -iname, and -type.
On Sat, 16 Aug 2025 00:20:08 -0000 (UTC), candycanearter07 wrote:
Lawrence D'Oliveiro <[email protected]d> wrote at 22:45 this Thursday (GMT):
The “find” command has the ability to execute external commands.
Those can produce output on their own, and/or their success/failure
exit status can be used as a filter on matching files.
To be fair, "find" can be a bit of a rabbithole to learn.
The term for that is “deep” software: it doesn’t scare you with a
whole lot of complexity up front. Instead, it offers some initial
features that aren’t that hard to use, but the more you dig beneath
the surface, the more capabilities you find. This is why it’s good
that the man page is always handy: you can keep going back to it and discovering new things as you need them.
Laicolasse:~ # time find / -type d -newermt "2025-07-28" \
! -newermt "2025-07-31" 2>/dev/null | tee busqueda
Turned out that an automount was happening of an external nfs mount on "/mnt/nfs/Isengard/xfsRaid/", and that raid is big and slow, the search
took for ever.
But lately what I use is "meld".
On Fri, 15 Aug 2025 04:55:04 -0000 (UTC), Rene Kita wrote:
Charlie Gibbs <[email protected]d> wrote:
Favourite one-liner:
grep foo * | cut -d: -f1 | uniq
Why not 'grep -l foo *'?
To “UUOC” (“Useless Use Of Cat”), we can add a new category: How about
“UUOCP” (“Useless Use Of Complicated Pipelines”)?
On Tue, 19 Aug 2025 12:06:04 +0200, Carlos E.R. wrote:
But lately what I use is "meld".
<https://meldmerge.org/> -- seems to do a lot.
On Tue, 19 Aug 2025 12:28:49 +0200, Carlos E.R. wrote:
Laicolasse:~ # time find / -type d -newermt "2025-07-28" \
! -newermt "2025-07-31" 2>/dev/null | tee busqueda
I never knew about -newermt. Why? Because it’s not listed in the man page, though it is documented in the info file.
Nope. Scratch that. It *is* documented in the man page, in the form of “- newerXY” with explanations of what “X” and “Y” can be.
Turned out that an automount was happening of an external nfs mount on
"/mnt/nfs/Isengard/xfsRaid/", and that raid is big and slow, the search
took for ever.
Wouldn’t “-xdev” (“don’t descend directories on other filesystems”) have
fixed that?
For example, after an update an rpm based system there are a lot of
.rpmold or .rpmorig files. I compare the config files with the other
version and easily copy over the new or the old lines into the
active file.
On 2025-08-20 02:59, Lawrence D’Oliveiro wrote:
Wouldn’t “-xdev” (“don’t descend directories on other filesystems”)
have fixed that?
But I need to scan both root and home, which are separate filesystems.
I just saw:
-xautofs
Don't descend directories on autofs filesystems.
which I have tested now and works! I feared it might work with the
classic automount but not with systemd. It does work. Nice!
On Wed, 20 Aug 2025 12:32:16 +0200, Carlos E.R. wrote:
On 2025-08-20 02:59, Lawrence D’Oliveiro wrote:
Wouldn’t “-xdev” (“don’t descend directories on other filesystems”)
have fixed that?
But I need to scan both root and home, which are separate filesystems.
I was going to say, explicitly list both / and /home (and whatever else)
as directories to search in, with -xdev to avoid entering any other mount points, but ...
I just saw:
-xautofs
Don't descend directories on autofs filesystems.
which I have tested now and works! I feared it might work with the
classic automount but not with systemd. It does work. Nice!
... that is probably simpler. ;)
However, it’s not present on my “find” version (findutils 4.10.0-3, part
of Debian Unstable as of last month).
On 2025-08-21 00:21, Lawrence D’Oliveiro wrote:
However, it’s not present on my “find” version (findutils 4.10.0-3,
part of Debian Unstable as of last month).
Wow. And I'm using openSUSE Leap 15.6, which has ancient versions of
almost everything.
Telcontar:~ # rpm -q findutils
findutils-4.8.0-150300.3.3.2.x86_64
Weird.
How about a list of favourite options to common commands?
Mine is "ls -ltr", which shows files in chronological order.
On Thu, 21 Aug 2025 02:29:57 +0200, Carlos E.R. wrote:
On 2025-08-21 00:21, Lawrence D’Oliveiro wrote:
However, it’s not present on my “find” version (findutils 4.10.0-3, >>> part of Debian Unstable as of last month).
Wow. And I'm using openSUSE Leap 15.6, which has ancient versions of
almost everything.
Telcontar:~ # rpm -q findutils
findutils-4.8.0-150300.3.3.2.x86_64
Weird.
The patch is actually older than that, dating from 2009 <http://fedora.riscv.rocks:3000/rpms/findutils/commit/29ef88d6c3ded9300b7c0c1b1a29321b287cab7a?style=unified&whitespace=ignore-all&show-outdated=>.
But it looks like it was never upstreamed into the GNU version <https://www.gnu.org/software/findutils/manual/html_mono/find.html>.
Nuno Silva <[email protected]d> writes:
BTW, is it just lack of coffee or both the online manual page and the
GNU info manual section for GNU diff do not explain/specify the default
output format? (Compare with IEEE 1003.1 [1].)
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/diff.html
The man page is little more than an option summary. The texinfo manual describes the default output format here:
https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Normal.html
On 2025-08-16 20:28, Rich wrote:
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using >>> "vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
The unified output (-u option) provides a 'diff' view that is much more
ameniable to being understood by humans.
diff --side-by-side --suppress-common-lines --ignore-space-change \
$1 $2 | less -S
But lately what I use is "meld".
Le 19-08-2025, Carlos E.R. <[email protected]d> a écrit :
On 2025-08-16 20:28, Rich wrote:
Stéphane CARPENTIER <[email protected]> wrote:
I never use "diff". I really don't like the way it's displayed. I'm using >>>> "vimdiff" or "nvim -d" a lot, because at the same time it's easier to
see what I want and it's easier to make the right changes.
diff's default output is an 'ed script' which is not very human
readable at all.
The unified output (-u option) provides a 'diff' view that is much more
ameniable to being understood by humans.
diff --side-by-side --suppress-common-lines --ignore-space-change \
$1 $2 | less -S
I'm still not convinced. OK, it's a little bit better to read than the default. But it's still very poor compared with vimdiff/nvim -d. And,
unlike vim/neovim, it's still useless to report some change in a file to another file.
But lately what I use is "meld".
OK, I looked at it a little bit, it's the same information level than vimdiff/nvim -v. But it looks more mouse driven than keyboard driven and
I'd have to learn something new.
On 2025-08-23 14:22, Stéphane CARPENTIER wrote:
Le 19-08-2025, Carlos E.R. <[email protected]d> a écrit :
But lately what I use is "meld".
OK, I looked at it a little bit, it's the same information level than
vimdiff/nvim -v. But it looks more mouse driven than keyboard driven and
I'd have to learn something new.
In my notes I have:
utils diff
kdiff3
tkdiff *
fldiff
meld - very good comparison editor
Le 23-08-2025, Carlos E.R. <[email protected]d> a écrit :
On 2025-08-23 14:22, Stéphane CARPENTIER wrote:
Le 19-08-2025, Carlos E.R. <[email protected]d> a écrit :
But lately what I use is "meld".
OK, I looked at it a little bit, it's the same information level than
vimdiff/nvim -v. But it looks more mouse driven than keyboard driven and >>> I'd have to learn something new.
In my notes I have:
utils diff
kdiff3
tkdiff *
fldiff
meld - very good comparison editor
Like I said unlike diff, it looks OK to have easily the most important informations about the changes. So, yes, it looks good. Now, I'm a
vimist, so if it doesn't bring me more than vim, I don't see the point
on using it. Never heard about it, never heard about the others neither.
Now, I'm a vimist, so if it doesn't bring me more than vim, I don't see
the point on using it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 170:55:32 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,855 |