Date: Sun, 15 Jul 2018 11:18:22 +0100 From: Roy Marples <r...@marples.name> Message-ID: <daea4764-15e2-d66e-2462-f0a96f697...@marples.name>
| If we're going to test that, then we need to check the converse for | ${hsort} && [ "$hostname" = "${hostname%%.*}" ] First irrelevant comment, the %%.* instead of #*. is an irrelevant variation, the only point of this comparison is to see whether there is a '.' in ${hostname} and both ways modify the expansion if a '.' appears, and leave it unchanged (and comparing equal) if not, so it makes no difference which is used (I originally wrote the line using % instead of # but then saw that you had used # elsewhere, and made it be consistent). It's different in the cases where you want to actually use the result of course. Hmm, now I look closer I see that you have used both forms already, (though the %%.* form is used where you are actually comparing different host name varss, so getting the value from it matters) so I guess this is even less relevant than I thought! More relevantly, and perhaps showing my extreme bias against short form hostname settings, but no, I would not do that - the short form can (and in the case in question, did) get set almost by accident. If the FQDN form is preferred, then overriding the "accident" (the kernel needing to config a name so it can boot over the net) is reasonable. On the other hand, if a FQDN has been configured, it is almost certainly deliberate, and probably should not be overridden. | The actual change required is a bit more invasive than that line change | though, but it suffices for this discussion. OK, I was guessing a bit, and I agree with the last sentiment. | The only other concern I have with this is that if we have two | interfaces and dhcpcd receives the same short hostname on both but only | a domain on one of them, then the hostname will flip-flop between short | and long hostnames. I'm not sure I see that (and in any case that kind of server mis-config is likely to cause issues anyway) but I will accept your more experience in this area. And no, we would not want that. | This is probably unlikely, but is worth pointing out. Agreed - in any case this was just a (semi half baked, I certainly did not consider all of the ramifications) suggestion to see if there was some easier way to deal with the kernel self-configuring its hostname in a more automated way than exists now. It would be better if only that case was overridden, rather than the hostname=short in rc.conf form as well. | You're referring to this? | http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html | | >4 arguments: | The results are unspecified. Yes. | Well, Today I Learned something new I guess. As I (think) I said, in the script in question there probably is no issue, the "unspecified results" are because of what can happen if some of the args happen to look just like test operators. The test "language" was very badly defined (ie: not at all really.) To avoid problems with that, there are very specific rules about where to look for operators depending upon just how many args exist - with those rules, it is possible to use test safely. But when it gets to > 4 args (or even some cases with just 4) it is just too hard to create meaningful usage rules that anyone would understand or remember. | I suppose my only concern is speed ... that would not produce any more | subshells on NetBSD or any modern shell would it? Guess I should do some | testing around that. On NetBSD right now it probably would, the NetBSD sh forks itself into oblivion for the most trivial of excuses... But that will get fixed sometime hopefully not too far away (performance improvements are next on the sh fix agenda once the actual known bugs are all gone...) Most other shells, no, test (and [ ) is almost universally built in, and most modern shells do not fork unnecessarily to run benign builtin commands. But unless you're planning to run the expression in a tight loop, I really would not worry about it, compared with the cost of starting the shell to run the script, the cost of an extra fork to run an extra [ is noise (even when done a few times during the life of the script.) kre