Subj : Re: Windows vs Linux To : boraxman From : tenser Date : Thu Apr 28 2022 01:14:13 On 27 Apr 2022 at 11:02p, boraxman pondered and said... bo> te> bo> Treat '/' as an escape character. Always. Thats it. bo> te> bo> te> Nope. See what I wrote above, re-read your response, bo> te> and try to figure out how that would work. Particularly bo> te> since the pathname separator in both the shell and home bo> te> directory fields is '/' in /etc/passwd. bo> te> bo> The escape character means the next character is to be taken literally bo> and not translated. bo> bo> //etc//password bo> bo> Or, if you had a colon delimited file, you would insert colons which bo> were not to be taken as separators as /: bo> bo> \\n would mean take the newline as a literal, and not an end of record. You keep missing the point. Sure; that's how escape characters work. But now perhaps you can explain how you intend to retrofit an escape character into /etc/passwd given 50 years of installed base? How do you intend to do this on systems that share their authorization database via LDAP or NIS with hosts where it is difficult or impossible to update libc? What do you do about static binaries? What do you do about the many, many tools that were written without care for this new thing you want to introduce into an existing file format? And how does any of this address the problem of adding new fields, or changing existing fields? Recall that the genesis of this subtopic was your opining that delimited text files were somehow superior to CSV, which is itself a delimited text format, and your seeming objection (unclear; you never really addressed it) to my statement that delimited files have limitations. You seem to fixate on trivial technical details, like escape characters etc, while missing the larger technical issues. There's a reason the world has mostly moved to structured data formats, and it's not because developers or lazy or stupid or simply wow'ed by the shiny thing du jour. We all understand how escaping works. Experienced developers also understand that that is not the only issue at play. bo> te> Actually, lexical analysis of strings literals with embedded bo> te> quotes escaped by backslashes is a trivial regular expression: bo> te> /"(\.|[^\\"])*"/ bo> te> bo> te> Again, PowerShell is 15 years old. bo> bo> How has it changed the use of Windows for users such as me? Remember, bo> most users are like me, not software developers. I have no idea, but that's not the point. The point is that you can use the exact same model you point to with Unix on Windows. The Unix philosophy is not singular in the way you seem to be asserting it is; it's not even that rich on Unix. Both VM/CMS and Windows actually have _more powerful_ primitives than Unix/Linux because they bring notions of type safety and structure to the pipe primitive. If you aren't aware of the tools that are available on the platforms you are dismissing, and not aware of the limitations of the platforms you are lauding, perhaps you examine your opinions and refrain from voicing value judgments. bo> te> That is blatantly false. This is exactly how software is bo> te> built these days. Have you ever done professional software bo> te> development? bo> bo> I just don't see it. The basic paradigm is the same now as it was in bo> 1999. You may have data in an excel spreadsheet, to extract the data, bo> you have to open Excel, select the "File -> Open" option, open the file, bo> use Excels search functionality, find the record containing the key you bo> need, navigate to the cell which has the data you want, CTRL-C, then bo> switch to where you want to put the data, put your mouse pointer there, bo> CTRL-V. Repeat. What does that have to do with building software? Your statement was about software development, which is _radically_ different now than it was in 1999. Based on this comment alone, it seems likely your experience is limited to using machines, and you have very limited development experience. bo> The OS makes it *slightly* easier in that you can double click the file bo> in Explorer to open it, if the file is accessible via Explorer, which bo> may not be the case on a bespoke cloud storage system. bo> bo> The paradigm is unchanged. The data belongs to Excel, it is accessible bo> only through Excel, or perhaps a custom piece of code, maybe. We are bo> still using computers in terms of managing applications. Sounds like you find yourself in a soul-sucking deadening environment. I'm genuinely sorry for that; however, you continue to draw unwarranted conclusions about things generally based on your personal experience, which really does not follow. That's called anecdotal evidence, and is a known logical fallacy. bo> You might say "so what", in which case, I think that is the result of a bo> lack of imagination. Data, such as product master data, should be bo> independent of an application. It should be part of the system, the bo> system being the computing environment. Make data a first class bo> citizen, data belongs to the user, not the app, and make it available bo> for any piece of code to refer to. This is a strawman. I didn't say, "so what." Though I have no idea why you're bringing this up in response to a comment about software development, I will say that open data formats are de rigor now and have been for quite some time. Also, you seem unaware of a number of points, here. Namely, that you could simply programmatically extract the data you want from an excel file. There are APIs for this in most major programming languages and the formats themselves are standardized (ISO/IEC 29500-1:2016). If you run across a version of Excel that does not natively save in those standard formats, you can likely export to a format that is, or one easily groked by a library (even CSV!). In other words, this problem is easily solved, even on Windows. If there's a failure of imagination here, I'd say it is not even considering these possibilities. bo> In this respect, one can store product master data, and then use that bo> data to generate a document, or use it to validate data, or to run bo> queries about inventory. We need this functionality, and you can tell bo> this because what business does, is it seeks software which does all bo> this, such as a Quality Management System. The thing is ,these systems bo> are operating systems in and of themselves, which is why they tend to bo> stagnate, development and customisation is difficult, and outside the bo> scope of what the business can do itself because it is the vendors own bo> specific solution, instead of one leveraging core OS components and bo> tools. The result is sub-par, slow, error prone and costly, but no one bo> can see any better, because we're stuck with this idea that computers bo> are there to run Applications. bo> bo> Maybe Windows is ready to do this, perhaps, but it just plain hasn't bo> resulted in practical change. Again, you conflate the _system_ with the _application running on that system_, and assert that the former implies the structure of the latter. That is the part that does not follow. You don't seem to want to acknowledge that the system is just a tool, and haven't presented any serious evidence for any of your assertions beyond anecdote. Finally, you may find life a bit more pleasant if you took the time to look into solutions that are already available on the platform you are forced to work on, instead of looking rigidly at a different platform as the only solution. --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .