There are systems were imbedded CR is both valid and useful. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________ From: IBM Mainframe Discussion List on behalf of Rick Troth Sent: Friday, March 28, 2025 3:02 PM To: [email protected] Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!) External Message: Use Caution On 3/28/25 12:46 PM, Paul Gilmartin wrote: > On Fri, 28 Mar 2025 11:05:05 -0400, Rick Troth wrote: > >> EXCELLENT observation >> >> Postel's Law should be followed >> >> https://en.wikipedia.org/wiki/Robustness_principle >> > No. This leads to chaos. Developers are inclined to obey the > "be liberal in what you accept" which leaves no platform on which > to validate "be conservative in what you send." I strongly (though incompletely) disagree with your observation. I have always taken robustness to mean, for example, always send ASCII+CR+LF as a line of internet plain text, but *require* only ASCII+LF. If the CR is present, fine. It's going to get stripped out anyhow. (By whatever interpreter is crunching it. I'm not talking about files, necessarily.) Stuff like that is NOT chaos. > z/OS is conservative in what it accepts and I have had problems > building FOSS which was probably "validated" with the liberal gcc. > both senders and accepters whould obey the same rules, which > should be the Standard. Here is where I am "incomplete" in my objection to "conservative in what it accepts". I found that XLC (for normal C, not for C++) rejected a lot of my code where I had gotten lazy and used // for comments instead of proper /(* ... */. In hat case, I appreciate the compile time errors. They only made my code cleaner. But I have been bitten by IBM implementations where Big Blue were such sticklers for the rules that WIDELY accepted exceptions just did not fly. What a pain! It's like "right turn on read after stop" in all fifty states except for these three. Better to avoid the astonishment factor. Chaos indeed. >> Consumer systems REGULARLY have blanks in filenames, which makes >> scripted automation difficult. Other punctuation can also be troublesome. >> > Yes. There should be extensions to scripting languages to support > utilities generating tokenized lists of filenames. We could all go with Tcl. >> -- R; <>< > >> On 3/27/25 10:52 PM, Joel Ewing wrote: >>> Saying that any 8-bit combination is "supported" in file names and >>> paths by Unix is misleading. It would be very bad form to use a >>> character code that is not associated with a standard displayable >>> glyph, even if the creation of such a file were allowed, because >>> reliably working with a file with "invisible" characters in the name >>> after creation would be impractical. Special characters like >>> single-quote, double-quote, asterisk, question-mark, etc. may be >>> allowed, but are inadvisable because of their special semantic >>> significance when referring to files in commands and standard >>> utilities causes problems, Any broadning of file name rules in z/OS >>> would most likely need restrictions based on usage context as well. >>> >>> What is allowed and sometimes useful in current versions of Linux and >>> Windows is almost any other arbitrary standard Unicode glyph in file >>> and path names, represented in UTF-8. I would assume that multi-byte >>> characters count as that many bytes against the 255-byte limit. You >>> can use characters in non-Latin alphabets and even use special >>> symbols, such as in the file path >>> *~/gov_SNAFU/👊🇺🇸🔥.txt , *provided all the utilities you plan to >>> use with the file support fonts that provide the appropriate glyphs >>> and the system allows you to represent Unicode characters -- in this >>> case u+270A (✊), u+1F1FA u+1F1F8 (🇺🇸), and u+1F525 (🔥) -- by some >>> means that isn't too tedious. Linux provides Unicode text entry >>> support globally at the Operating System level. Windows >>> unfortunately requires that support to be provided by individual >>> applications, and not all provide it. >>> >>> JC Ewing -- -- R; <>< ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
