Re: cloner interface handling in rc.d/network

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 14 May 2021 14:01:13 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202105141801.OAA19839%Stone.Rodents-Montreal.ORG@localhost>

  | >> 3a [ ! ... ]�should better be written ! [ ... ], no?
  | > Probably yes, but it works either way.
  |
  | I see no reason to prefer either over the other.  What am I missing?

The rules for 3 arg test are that if the 2nd arg is a binary operator
then that wins, so should someone create a version of test where -f
(or whatever) is a binary operator (in addition to its unary operator
function) then the meaning would suddenly change.   This is a very
remote possibility at best, but using the ! [ -f foo ] variant makes
sure that can never happen.

The ! as a test operator was created when sh had no ! function, and
when people were used to using test with many args (with -a, -o,
parentheses, etc) where it made sense - assuming you could cope with
the heuristic way that test guessed what was intended.  If we were
defining it now there would be no ! operator in test, it simply isn't needed.

  | >> 3b ! [ ... ]�&& foo could be written [ ... ] ||�foo
  | > It could, but that would alter the semantic slightly.
  |
  | How would it alter the semantics?  The only way I can see is that it
  | would alter the status returned from the construct in the case where it
  | doesn't run foo.

Yes.  The point was that this kind of De-Morgan transformation isn't
always safe to do with sh code, the minor variations in the results can
sometimes be important.  Not here, which is why the "It could".

  | Does -f accept a symlink to a plain file?

Yes.

  | The presence of -h argues
  | that it uses lstat(), but it might do so only for -h.

It does (only for -h and -L).

  | In theory, there's also the question of what happens if there is a file
  | called, say, /etc/ifconfig.tun0* (the * being part of the name).

If you have an interface called tun0* then it will configure it, as
it should.   Otherwise it will attempt to, and fail.

  | As another possible issue, consider a cloner interface called, say,
  | tun0foo, whose unit 1 would be tun0foo1, whose file would match the
  | tun0* pattern.  (Obviously, not a concern with the current crop of
  | cloners, but nothing prevents someone from implementing one, right?)

Just common sense.   Interface names don't contain digits generally,
just the unit number part.   You might be surprised just how much
would break if that assumption is no longer maintained.

  | More serious, to me, is that it pays attention to only files, ignoring
  | any possible ifconfig_$int$num variables.

I didn't write the code, so I'm not sure if any attempt was made to
allow those things (personally I don't like them, I prefer the files,
though I'd prefer they not live directly in /etc).

  | > Not sure why ## rather than # - in the case where an interface was
  | > named foo3.7 or something the ## variant is likely to fail.
  |
  | Possibility: maybe it was adapted from something that gathered files
  | from subdirectories, many of which might have dots in their names, and
  | that particular bit of syntax was never updated?

Perhaps.   I have no idea.

  | I'm not sure whether I think it's more likely that the /etc/ifconfig.
  | prefix would be changed to grow another dot or that a cloner interface
  | with a dot in its name would appear.  Neither feels very likely to me.

Nor me, but a change to the /etc/ifconfig part (though probably not by
inserting dots) seems the more likely of those possibilities.

  | Um?  What prevents a cloner from having a name like x.y.z?  I haven't
  | looked at the code, but that seems like a peculiar restriction.

It may be able to, I haven't checked that either.   It isn't likely.

kre