q: boolean variable handling policy

	Hello,
there was an IRC discussion regarding ltsp-altlinux branch
modifying ltsp-common-functions:

http://tinyurl.com/2yf3gq

Basically boolean_is_true() is complemented by boolean_is_false()
for cases when default behaviour might differ depending on
"conscious yes/no", and then is_yes()/is_no() shortcuts for
these.  The reason is explained below.

Vagrant told he's uncomfortable with this revision:

---
<vagrantc> gvy: definitely don't like the changes to
           ltsp-common-functions ...
<vagrantc> gvy: i refuse to use 0 and 1 as booleans in shell
	   scripts, because the potential for confusion is *huge*
<vagrantc> gvy: and boolean_is_false could merely be a negation
           of boolean_is_true.
<vagrantc> gvy: is_yes and is_no just seem pointless.
<gvy> vagrantc, well you're not forced to use is_* or 0/1 :)
<vagrantc> gvy: but there's *no* point to it.
<vagrantc> gvy: if support for it is in the code, people may use
           it, and i object to allowing those changes.
<gvy> vagrantc, for us, there's no point in heaps of stuff in
      ltsp... [ -n "$(echo ... | grep ...)" ] is horrific as well
<gvy> vagrantc, and i can provide at least one case *for* using
      distinct tests for "true" and "false"
<gvy> it's when you default to different things
<gvy> basically "if yes, or otherwise..."
<gvy> and "if no, or otherwise..."
<gvy> my shell scripting experience had quite a few of such cases
<vagrantc> gvy: it is possible, yes.
<gvy> vagrantc, and i don't mind if there's proper discussion and
      these are dropped with reworking the code to clean it up
      along the agreed boolean standard :)
<vagrantc> gvy: well, until we have that discussion, i reject the
           changes.
<gvy> but frankly, i'm surprised to see such strong opposition to
      such simple thing
<vagrantc> i've got to go now.
---

So while this wasn't sorted out online, I'm taking discussion
"offline" so that it doesn't demand immediate replies (but still 
does need ones).

Got three of them: 

1) whether there is any particular policy on boolean value
   handling;
2) whether there's more general one (README-DEVELOPMENT-POLICY
   hints there's none fixated)
3) and how generally the collaboration is going on here.

The latter might require some more bytes...


I'm quite easy with sed -ir on is_yes/is_no but I'd really want
to understand the rationale after the unsung pieces of
server/doc/CodingStyle.

Knowing that there's always a taste difference and technical
difference, we've tried to avoid hitting the former pretty hard
during preparation of that particular branch.


It would be fine to understand that our code is not aesthetic, 
or breaks things, or is not safe.  But with a reason.

It is somewhat hard for me to argue on whether !boolean_is_true()
is *NOT* equal to boolean_is_false(), because it isn't in my
shell scripting practice (it's not that long though, since 1998).

There ain't really booleans in POSIX shell.  So we use strings.
These can be empty (even unset).  This does make a difference.
This is where I consider there's a technical reason to reject 
a taste, not a code.


Further, it's hard to talk aesthetics when bits and pieces like
this one are in place *as the last command in a script*:

[ -e /selinux/enforce ] && /sbin/restorecon -R $TFTPDIR &> /dev/null

Shell scripts aren't written that way!  bash(1) tells:

       Bash's exit status is the exit status of the
       last command executed in the script.

So to avoid the non-zero error level of that test resulting in 
non-sero exit code of the whole script being interpreted (usually
leading to more breakage), it must be written the other way:

[ ! -e /selinux/enforce ] || /sbin/restorecon -R "$TFTPDIR" &> /dev/null


I'm thankful to Vagrant for all the patience and help he's done
to me, but now I frankly don't understand where the "taste" and
"technical reason" border is here.

I'm all for making LTSP scripts *beautiful*, currently not being
even "good" on that scale.  (actually, LTSP4.2's startx made me
crawl the wall and not look into it for three more months until
could do it again :-(  no joke, one can ask our CTO)

For an example of decent shell scripts, I propose for your
reading pleasure this excerpt from libshell by Alexey Gladkov
(ALT Linux):

http://tinyurl.com/3bc3cm

and this one by Solar Designer (Openwall Project) and
Dmitry Levin (ALT Linux, Openwall Project):

http://tinyurl.com/2z7h8b

I think it might be a honor to see LTSP scripts at that level 
of clarity, modularity, reliability and security as Owl ones.

And I think that we're going to go there.  Hope that "we" here
will mean all of the project, not us two.

Thank you, those who had patience to get this far. :)


PS: there was at least one other uneasy point, a separate message
seems appropriate.

PPS: I'm OK with sorting all of these things out _after_ folks
got the spring releases out, we just have to keep a 90K patch
(including plugins) between ltsp-trunk and ltsp-altlinux in.

-- 
 ---- WBR, Michael Shigorin <mike-u2l5PoMzF/[email protected]>
  ------ Linux.Kiev http://www.linux.kiev.ua/

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net