Re: [Dorset] Discovering unfamiliar utilities

2019-07-06 Thread Patrick Wigmore
On Sat, 06 Jul 2019 09:33:15 +0100, Ralph Corderoy wrote:
> Well, I was wondering how it could be done and like solving the
> puzzle; keeps my hand in.

A good habit, for sure.

> The university used to have staff and students interested in Unix
> and ran Solaris or a descendant so there could be quite a few good
> books from those times.

I remember (or misremember) seeing a publicity shot of a Solaris lab 
at the university, probably about ten years ago. The lab was bathed in 
golden yellow light, which seems appropriate if the photo was taken in 
its sunset years. (And also because it was Sun.)

I think they had labs of PCs dual-booting Linux and Windows when I 
attended an open day a few years ago, and a room with all the walls 
decorated with shell scripts, penguins and the like.

Thank you for yet more book recommendations.

Patrick

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-06 Thread Ralph Corderoy
Hi Patrick,

> > For a one-off quick task, automating it would be more tedious.
>
> But you did it anyway, even though you didn't need the results!

Well, I was wondering how it could be done and like solving the puzzle;
keeps my hand in.  What I did was O(n²) though, where n is the number of
files.  For production, fgrep's patterns should be calculated just once.

> There seems to be a copy of it in the library at Bournemouth
> University.  https://capitadiscovery.co.uk/bournemouth-ac/items/91529
> At some point I will head over there to have a read and see what's
> nearby on the shelves

The university used to have staff and students interested in Unix and
ran Solaris or a descendant so there could be quite a few good books
from those times.  Skimming
https://capitadiscovery.co.uk/bournemouth-ac/items?query=subject%3A%28UNIX%29=publishedyear
I see decent ones they have include

Stevens' Unix network programming.
Levine's Lex & yacc.
McKusick's Design and implementation of the 4.4BSD operating system.

A book well worth reading they've got is Jon Bentley's ‘Programming
Pearls’.  He was at Bell Labs and uses the Unix shell and small C
programs to tackle many interesting problems.


https://capitadiscovery.co.uk/bournemouth-ac/items?query=subject%3A%28UNIX%29=publishedyear

They also have Aho, Hopcroft, and Ullman's ‘Data structures and
algorithms’ if you like that kind of thing.  Bell Labs again, they
invented some of them and ‘wrote the book’.

I found the search's ability to list the oldest books first useful;
if they have an old book then it's probably one of the classics.

-- 
Cheers, Ralph.

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-05 Thread Patrick Wigmore
On Fri, 05 Jul 2019 12:14:03 +0100, Patrick Wigmore wrote:
> the short description of size(1) does not make any mention of object
> files:
>
> $ man -f size
> size (1) - list section sizes and total size.

On Fri, 05 Jul 2019 13:33:21 +0100, Ralph Corderoy wrote:
> This is a bug that you may like to report

The latest version 2.32 contains the same description, so I reported 
Bug 24777 against binutils.
https://sourceware.org/bugzilla/show_bug.cgi?id=24777

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-05 Thread Patrick Wigmore
On Fri, 05 Jul 2019 13:33:21 +0100, Ralph Corderoy wrote:
> For a one-off quick task, automating it would be more tedious.

But you did it anyway, even though you didn't need the results!
(Don't change, your code snippets are great.)

> I learnt by reading books.  Pre-Internet.  The authors back then
> typically put a lot of effort into providing a coherent progression
> through the subject.

That's exactly why I think books (and courses) are valuable. I don't 
see them as a thing of the past. Other resources can sometimes provide 
quick answers, or an overview of current thinking, but I tend to turn 
to books when I want a solid, baseline understanding of a well-
developed topic.

The main difficulty I have with books is discovering the right ones, 
and I suppose I was fishing for a book recommendation, so thank you 
for recommending 'The Unix Programming Environment'.

There seems to be a copy of it in the library at Bournemouth 
University.
https://capitadiscovery.co.uk/bournemouth-ac/items/91529

At some point I will head over there to have a read and see what's 
nearby on the shelves; that usually turns up something good. (If I can 
figure out how to navigate the ever-changing maze of new buildings on 
their campus.)

> This is a bug that you may like to report

Good point. I'll see about doing that later.


On Fri, 05 Jul 2019 14:05:30 +0100, Bob Dunlop wrote:
> The command was simply "ldd /usr/bin/nvi" which shows the list of
> object dependencies, then cut and paste library names I'm interested
> in into the size command.

That makes sense. I thought there might have been a magic one-liner 
that knew which ones to omit, but in hindsight I suppose you need 
quite a bit of context to decide which libraries are relevant, so it's 
not as plausible as I thought.


On Fri, 05 Jul 2019 14:44:22 +0100, John Carlyle-Clarke wrote:
> You reminded me that a few days ago I listed the files in a core
> package on a server (looking for a missing utility) and saw a few
> things in the list that I didn't immediately recognise. I thought
> at the time, "That would be a good way to learn about utilities
> that I don't know exist".

That's true. Package management is a good way to find things, and 
there is usually some kind of categorisation in place as well. 
Certainly a useful tool to keep at hand.

Patrick

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-05 Thread John Carlyle-Clarke
You reminded me that a few days ago I listed the files in a core package on
a server (looking for a missing utility) and saw a few things in the list
that I didn't immediately recognise. I thought at the time, "That would be
a good way to learn about utilities that I don't know exist".

The downside is that it's system-dependant, and you have to know or guess
the names of the important packages.

On my system, anything called "*utils" is likely to be worth looking into.

#~ pacman -Q | grep "utils"
binutils 2.32-2
bluez-utils 5.50-6
bridge-utils 1.6-3
ca-certificates-utils 20181109-1
cifs-utils 6.8-2
coreutils 8.31-1
desktop-file-utils 0.23+4+g92af410-1
diffutils 3.7-1
exfat-utils 1.3.0-1
findutils 4.6.0-4
inetutils 1.9.4-7
iputils 20180629.f6aac8d-4
jfsutils 1.1.15-6
keyutils 1.6-1
pciutils 3.6.2-1
pcmciautils 018-8
python-docutils 0.14-2
sg3_utils 1.44-1
sysfsutils 2.1.0-10
usbutils 010-1
v4l-utils 1.16.6-1
xdg-utils 1.1.3-3
xorg-font-utils 7.6-5
xorg-xkbutils 1.0.4-3

#~ pacman -Ql binutils | grep /bin/
binutils /usr/bin/
binutils /usr/bin/addr2line
binutils /usr/bin/ar
binutils /usr/bin/as
binutils /usr/bin/c++filt
binutils /usr/bin/dwp
binutils /usr/bin/elfedit
binutils /usr/bin/gprof
binutils /usr/bin/ld
binutils /usr/bin/ld.bfd
binutils /usr/bin/ld.gold
binutils /usr/bin/nm
binutils /usr/bin/objcopy
binutils /usr/bin/objdump
binutils /usr/bin/ranlib
binutils /usr/bin/readelf
binutils /usr/bin/size
binutils /usr/bin/strings
binutils /usr/bin/strip

On Fri, 5 Jul 2019 at 12:14, Patrick Wigmore  wrote:

> On Thu, 04 Jul 2019 10:37:35 +0100, Bob Dunlop wrote:
> > nvi
> >textdata bss dec hex filename
> >   270612048 256   2936572b5 /usr/bin/nvi
> >  442019   18688 144  460851   70833 /usr/lib64/libvi.so.0
> >  430302   176282552  450482   6dfb2 /lib64/libncursesw.so.6
>
> This type of output was not something I was familiar with. I can see
> that size(1) produces output in this format, given a list of object
> files, but what method did you use to produce the list of files,
> excluding common operating system libraries?
>
> More generally, this highlighted to me a gap in my knowledge about how
> to discover utilities that fill a particular need without first
> knowing their names. I had already forgotten the route I took to
> discovering size(1) within minutes of discovering it. It began with a
> web search for the column headings in the output and ended with some
> poking around on the local system.
>
> I discovered ldd(1) in a similarly poorly remembered fashion, but it's
> clearly not the whole solution.
>
> I was inspired to read man(1)'s manual page and to belatedly try out
> man -k and man -K. However, it is difficult to devise keywords that
> are specific enough to select the right manual pages and generic
> enough to appear in their short descriptions.
>
> For example, the short description of size(1) does not make any
> mention of object files:
>
> $ man -f size
> size (1) - list section sizes and total size.
>
> Even if it did mention object files, that would need to be the
> terminology that came to mind if I wanted to find size(1) using:
>
> $ apropos -a object size
>
> (It seems to me that man -k has no direct equivalent to the -a option
> of apropos.)
>
> So, I still feel in want of a good categorised summary of well-known
> commands, or at least a search technique that can expand my search to
> include conceptually-related terms.
>
> Patrick
>
> --
>   Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
>   Check to whom you are replying
>   Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
>   New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk
>
-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-05 Thread Bob Dunlop
On Fri, Jul 05 at 12:14, Patrick Wigmore wrote:
> On Thu, 04 Jul 2019 10:37:35 +0100, Bob Dunlop wrote:
> > nvi
> >textdata bss dec hex filename
> >   270612048 256   2936572b5 /usr/bin/nvi
> >  442019   18688 144  460851   70833 /usr/lib64/libvi.so.0
> >  430302   176282552  450482   6dfb2 /lib64/libncursesw.so.6
> 
> This type of output was not something I was familiar with. I can see 
> that size(1) produces output in this format, given a list of object 
> files, but what method did you use to produce the list of files, 
> excluding common operating system libraries?

The command was simply "ldd /usr/bin/nvi" which shows the list of
object dependencies, then cut and paste library names I'm interested
in into the size command.

As for how to locate an unknown command I don't know, in my case it's
too many years of experience.  Since you already know about apropos
and it's limitations I can only suggest DuckDuckGo is your friend.
Or https://unix.stackexchange.com/search is good for a lot of technical
questions.

-- 
Bob Dunlop

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk


Re: [Dorset] Discovering unfamiliar utilities

2019-07-05 Thread Ralph Corderoy
Hi Patrick,

> but what method did you use to produce the list of files, excluding
> common operating system libraries?

I expect Bob used ldd(1) and then removed common ones by hand, knowing
what they were likely to be.  For a one-off quick task, automating it
would be more tedious.

set /usr/bin/{true,vim,gimp}

needed() { ldd "$@" | awk '$2 == "=>" {print $3}'; }
for f; do
echo $f
needed $f | fgrep -vf <(
needed "$@" |
sort |
uniq -dc |
awk '$1 == '$#' {print $2}'
) |
xargs -rd\\n size -t
echo
done

> I was inspired to read man(1)'s manual page and to belatedly try out
> man -k and man -K.

Yes, I do use apropos(1).

> For example, the short description of size(1) does not make any 
> mention of object files:
>
> $ man -f size
> size (1) - list section sizes and total size.

This is a bug that you may like to report; it needs ‘of object or
archive files’ appended.  The DESCRIPTION section says as much.  It also
shouldn't end the description with a full stop.

> So, I still feel in want of a good categorised summary of well-known
> commands, or at least a search technique that can expand my search to
> include conceptually-related terms.

I learnt by reading books.  Pre-Internet.  The authors back then
typically put a lot of effort into providing a coherent progression
through the subject.  ‘The Unix Programming Environment’ is an old
classic if you're also interested in programming on Unix.
http://amzn.to/16SVwhD

And the man pages came printed on paper from Sun along with a permuted
index.  Just reading down that index was a good way to find new things
to learn; especially as they paid editors to ensure good NAME sections.
https://en.wikipedia.org/wiki/Ptx_(Unix)

After books came mailing lists and Usenet groups where you'd learn to
spot the knowledgable writers.

Ideally, ‘every day's a school day’.  :-)

-- 
Cheers, Ralph.

-- 
  Next meeting: BEC, Bournemouth, Tuesday, 2019-08-06 20:00
  Check to whom you are replying
  Meetings, mailing list, IRC, ...  http://dorset.lug.org.uk/
  New thread, don't hijack:  mailto:dorset@mailman.lug.org.uk