Live data from Hacker News

Uniform eXchange Format (UXF) – plain text human readable typed storage format

github.com

61–62 of 62 posts

Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format

#61

Earlier quoted context omitted.

The Norway problem came to mind for me, too, but I don't think there's much opportunity for that to arise here given that strings are quoted. Meanwhile, there's plenty of other precedent for yes/no instead of true/false; shell scripts come to mind. I don't know if I prefer this over treating everything as a string and letting readers/writers decide on their own how to parse things, but it seems like a much more reaso…

Yes, I agree, the format described here is more reasonable than YAML and would not suffer from the Norway problem. I'm interested in what you mean when you mention shell scripts; I find it more idiomatic to write: if [ true ]; then echo test; fi Over if [ yes ]; then echo test; fi Because the behavior is more consistent when you try to use it in other constructs: while true; do echo test; done Versus yes | while read…

> Is there a particular instance of yes/no in shell scripting that you had in mind?

Yes!

I see them all the time in various build scripts, especially for Slackware packages / SlackBuild scripts; it's a pretty common convention to use yes/no values for enabling/disabling (respectively) various build options.

OpenBSD's rc.conf(.local) also uses "NO" to indicate that a service/daemon should be disabled entirely; for example, the default httpd_flags=NO in rc.conf entirely disables httpd - unless, of course, you re-enable it later with httpd_flags= in rc.conf.local. "YES" is also sometimes used, e.g. library randomization being enabled by default via library_aslr=YES.

Post reply on HN