Brock Pytlik wrote: > Shawn Walker wrote: >> [snip] >>>>> >>>>>> Why is it that we're testing properties against "none" versus just >>>>>> being >>>>>> set to the empty string? It seems like it will work, but I don't >>>>>> really >>>>>> get the idiom. >>>>>> >>>>> I went with none because it was the default/empty value for several >>>>> properties already. I'm much happier with checking the empty >>>>> string, but 'none' seemed to be the consensus in the manifest. I'll >>>>> change it and the manifest to use empty strings instead of none and >>>>> see if there are problems or complaints about it. >>>> >>>> This was done on purpose. >>>> >>>> My reasoning was as follows: >>>> >>>> --log-access and --log-errors have three special values each >>>> indicating logging destination *explicitly* (stderr, stdout, none) >>>> and anything else is assumed to be a filename if present. >>>> >>>> An empty string creates ambiguity in the command-line parsing for >>>> this reason: >>>> >>>> ./depot.py --log-access= --readonly >>>> ./depot.py --log-access --readonly >>>> >>>> ...while I know that this is a side-affect of how long-options are >>>> parsed, it's also very annoying to me. >>>> >>>> As such, I would avoid "empty string" for the reason above and >>>> change --proxy-base instead to allow a value of "none" in depot.py >>>> for the same reason it's done for the logging parameters if you must >>>> change it. >>>> >>>> Danek and I recently discussed this topic in this thread: >>>> http://mail.opensolaris.org/pipermail/pkg-discuss/2008-October/007257.html >>>> >>>> >>>> I strongly prefer having an explicit destination value of "none" for >>>> the logging commands over just using an empty string since that is >>>> consistent with the other options of "stdout" and "stderr". >>>> >>>> Cheers, >>> Well, the nice thing about using this ksh script is that now the >>> depot never sees --log-access= or --log-access. If the option isn't >>> set, the flag never appears at all. >> >> Right, but I was trying to keep the SMF usage scenario consistent with >> the "user using this from the command-line case" scenario. >> >> However, if this change is only going to affect the SMF scenario, I >> have no strong objections. >> >> Cheers, > > To me, this means the SMF use is more consistent with the command line > since I think most users would omit a flag, rather than setting it to > none explicitly. Since we've converged though, I suppose the details > don't matter much.
The problem with that is omitting --log-errors from the command-line *is NOT* the same as --log-errors=none. There are some internal defaults for --log-errors and --log-access, by specifying --log-errors=none you are explicitly stating that you do not want errors logged, as an example. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
