On 15.08.21 09:43, o1bigtenor via Dng wrote:
  > I'm finding myself occasionally drowning in information resulting
in me
  > trying to improve the connection between what I'm working on AND
the
  > information that I'm collecting.

 
  ...

> Dig some digging and hard links to directories are a no no
(!!!!!!!!!) - -
  > like forbidden.

They don't work, so it's necessary to link directories by soft links.
  That works for me where the topic overlap is greater than single
file
  granularity, i.e. the whole directory topic fits under two or more
  broader categories.

> I could see hard links being useful for what I want where soft links
are
  > going to break (have had the joy of breaking some myself and
causing myself
  > all kinds of joy in the process).

Yes, linking files works superbly. Soft links do break if you move the

  link target, so are less robust than hard links. My strongest
reason for
  preferring hard links is that you can delete _any_ of the linked
files
  at will, and only when the link count reaches zero will the one
copy be
  deleted. I.e. it is self managing; you can't lose all copies on one
  deletion by whacking the link target. But you can only use it at
the
  individual file level, so soft links are also useful.

> Any ideas out there on how to find such an ecosystem?

It is a home-cooked meal, made with available ingredients. I have used
  the method for about 3 decades now, not least for organising my
  collection of component datasheets. An opto-interruptor may for
example
  be reached in:

Embedded/device_data/sensors/opto-interruptors/
Embedded/device_data/opto/interruptors

Since that applies to all such devices, I soft link those directories.

There is currently only one hard link:

$ find Embedded/device_data/ -links +1 | grep pdf
  Embedded/device_data/transistor/small/pnp/2N6520.pdf
  Embedded/device_data/transistor/small/npn/2N6517-2N6520.pdf

And that is because 2N6517-2N6520.pdf describes both NPN and PNP
devices
  in a single datasheet. (Naughty, but easily managed with a link for
the
  one part number affected.)

Now, using tab filename completion, the directory tree serves as a
menu
  system, with some devices accessible via more than one path. That
  minimises the "Rat in a maze" problem made worse by any menu system
  which forces the user through a single path to a destination. We
  approach from different perspectives at different times, and user
  convenience is the primary, perhaps only, figure of merit for such
a
  system.

> (I don't think a RDMS is what I want because then how does one store
  > directories inside the topic - - - its almost like a RDMS that
has a system
  > inside it might do - - - argh - - - I think I'm getting more
confused
  > rather than less in trying to set up something - - - argh!!)

Unless you _need_ to perform relational merges on columns of data,
then
  a RDB is mastodon masquerading as a horse. It is unnecessarily
difficult
  to climb aboard, and it eats far too much for the little it can
  contribute.

Does that mean that no use can be found for tools in this tunnelling
  data tree? Nope. When I recall part of a part number, and just want
it
  displayed now, I invoke a simple script which finds matches. On a
single
  match, it invokes xpdf to display the datasheet. On multiple
matches, it
  lists their full paths, with full device numbers, allowing a
  double-click pick-up for pasting after "xpdf " on the command line.
So
  far, that has sufficed to make the facility very comfortably
useful. If
  I ever feel a need for another bell or whistle, all of *nix is at
my
  fingertips to whip up a custom solution on a whim. No monolithic
product
  can compete with that, especially if encumbered by a GUI. Here's
the
  script, FWIW:

xe ()
{
    if [ $# -eq 0 ]; then
        echo -e "ntLocate in ~/Embedded, & xpdf if
unique.nntUsage: xe 'part'  # e.g. 'LM345'nn";
    else
        z=*$1*pdf;
        x=`find ~/Embedded -name "$z" | sort`;
        n=`echo $x | wc -w`;
        if [ $n -eq 1 ]; then
            xpdf $x;
        else
            if [ $n -eq 0 ]; then
                echo -e "t       xe: No match for
$z";
            else
                for i in $x;
                do
                    echo $i;
                done;
            fi;
        fi;
    fi
}

The maintenance effort converged on zero long ago. Adding new
datasheets
and categories amount only to a mv from the Download directory, and a
mkdir, respectively. I.e. Essentially effortless.

Erik