A circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex
-
@Salamander said:
@flabdablet said:
Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing : " / \ | ? or *
Still better than having a file whose name is the bell character. Or the newline character (Watch in awe as every shell script breaks on that one!).
Unix does have a choice when it comes to fixing bugs, you know.
They could develop a new API, and keep the old one around for legacy reasons. Then new programs could access the non-buggy, new API. Without affecting backwards compatibility.
But that wont happen, will it? It would require admitting that shit is broken or badly designed.Ah, the classic Unix prank of creating a directory full of read only files named * in someone's home directory.
-
@joe.edwards said:
I'd love to see volume letters go the way of the dinosaur. I know this will never happen, but I really love being able to mount arbitrary devices and shares anywhere in the filesystem in Linux.
You know NTFS supports something pretty damn close to Unix-style mount points with reparse points/junctions, yes? Plus, current drive and current directory are separate things in Windows; so if you want, you can just set the current drive to C: and do everything else with Unix-ish paths like "\Users\joe.edwards\my-mounted-fs-root".
It causes far less trouble to learn your chosen environment's cultural norms, though, and stick with those. When in Rome, etc.
If mounting arbitrary devices in arbitrary spots floats your boat, have a look at GNU Hurd, whose "translator" concept makes that exceedingly easy to do. Arbitrary mounts don't need superuser privileges, or FUSE-style workarounds for the lack of them, either; if a user has appropriate access rights to a filesystem's container, that filesystem can be accessed via a translator and mounted anywhere in the namespace tree that the user has access to. Debian is now available with a Hurd kernel, so you can actually run a surprising amount of stuff on it.
@joe.edwards said:
I actually use Windows as my primary operating system, mainly because my work is all .NET and T-SQL, and at home I want to play new games... but I basically love the Linux philosophy, open source, the Bourne Again shell, text file configuration, Aptitude, the GNU toolchain - all the stuff Blakey hates so passionately.
Most of my paid work is with Windows, because I netadmin a school that's rusted onto a bunch of key Windows apps and Active Directory user account management, and it's what the teachers and admin staff are used to so it's what we run. But all my home boxes run Debian, and I also use it at the school in non-end-user-visible roles like VM hosting, VLAN management and workstation re-imaging. And I come home from a tiring day herding the Windows cats and jump on a Debian box to relax :-)
I'm glad that Blakey and you and I all have access to tools that fit the way our minds work and allow us to be and feel productive. I think the IT world would be a far poorer place without that kind of cultural diversity, which is why I get so sad when I see people who should be smart enough to know better fighting passionately over the One True Tool or the One True Design Philosophy or the One Worthy Design Goal as if there were such things. I think we'd all benefit from learning to take our religions less seriously.
But I cannot bring myself to like or appreciate The Ribbon. Just can't do it.
-
@MiffTheFox said:
@Salamander said:
@flabdablet said:
Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing : " / \ | ? or *
Still better than having a file whose name is the bell character. Or the newline character (Watch in awe as every shell script breaks on that one!).
Unix does have a choice when it comes to fixing bugs, you know.
They could develop a new API, and keep the old one around for legacy reasons. Then new programs could access the non-buggy, new API. Without affecting backwards compatibility.
But that wont happen, will it? It would require admitting that shit is broken or badly designed.Ah, the classic Unix prank of creating a directory full of read only files named * in someone's home directory.
I prefer making a file named con. Or lpt1.
-
@Salamander said:
Still better than having a file whose name is the bell character. Or the newline character (Watch in awe as every shell script breaks on that one!).
Writing scripts that don't break when fed pathological filenames is not only an excellent way to learn how to write robust scripts, but a good opportunity to reflect on and appreciate how much easier it is to do that using a Bourne shell descendant than a CP/M descendant. Bourne shell has quoting mechanisms that are robust enough to stand up to all those edge cases, just by using them the way they were designed to be used. Doing similar things in cmd requires endless fartarsing about with obscure features known only to those who have tracked them down experimentally, and even then there are cases that simply cannot be handled at all.
Pathological pathnames are generally not a problem in languages like Javascript, where string data can never appear as a bare (unquoted) literal. On the other hand, the syntactic clues that those languages use to achieve that hygiene make them more long-winded to use as command line interpreters. I really enjoy using Bourne shell and variants, because they sit right in a sweet spot between conciseness and generality.
@Salamander said:
Unix does have a choice when it comes to fixing bugs, you know.
They could develop a new API, and keep the old one around for legacy reasons. Then new programs could access the non-buggy, new API. Without affecting backwards compatibility.
But that wont happen, will it? It would require admitting that shit is broken or badly designed.Actually that happens all the time; take a look at the kernel system call API, or ACL support via extended attributes in filesystems, for good examples. Fixing everything by reinventing it can easily be taken too far, though.
You will also find admissions that shit is broken or badly designed in almost every man page; most of those have a Bugs section.
-
@flabdablet said:
Writing scripts that don't break when fed pathological filenames is not only an excellent way to learn how to write robust scripts,
Actually, this guy says it's literally impossible to do in a portable way. He claims it's only possible by going outside of the standard.
In any case, making things pointlessly difficult as a learning exercise is basically the worst idea ever. But that's ok, I know you don't mean it. What you really mean to say is, "goddamned it's broken as shit" but since you can't admit that, your brain struggles-- smoke emerging from both ears-- to find a possible explanation. "It's been years!", your brain thinks, "why isn't this fixed? Wait-- wait-- I know! It's a learning exercise!" Aha, now you can come here to this forum and explain to us why Linux allows such obviously broken filenames... because if they weren't broken, even a non-expert would be able to write correct scripts!
... oh wait that still makes it sound like a bad thing.
@flabdablet said:
Actually that happens all the time; take a look at the kernel system call API, or ACL support via extended attributes in filesystems, for good examples. Fixing everything by reinventing it can easily be taken too far, though.
You're missing the point of CADT. The point isn't that it's reinvented (well-- that's half the point I guess), the real point is that it's reinvented without bothering to find whether the reinvention actually fixes any of the problems the old version had.
@flabdablet said:
You will also find admissions that shit is broken or badly designed in almost every man page; most of those have a Bugs section.
So instead of fixing the bugs, they just admit they exist? Like, if my software is shit, it's ok as long as I'm self-aware that it's shit? And of course the concept of "pride" or "craftmanship" never enters into the equation-- ship early! Ship often! Ship broken! Who gives a shit!
-
@flabdablet said:
Writing scripts that don't break when fed pathological filenames is not only an excellent way to learn how to write robust scripts, but a good opportunity to reflect on and appreciate how much easier it is to do that using a Bourne shell descendant than a CP/M descendant. Bourne shell has quoting mechanisms that are robust enough to stand up to all those edge cases, just by using them the way they were designed to be used.
I'm sure it does. Doesn't make it any less retarded having to use them.
It gets pretty insane when you want to use grep, or worse, sed on a list of filenames.
Just because something is possible doesn't mean it's a very good idea.
Besides, writing perfectly flawlessly robust scripts is so difficult that other people just assume there won't be any weirdly named files. If they even know that it's possible in the first place.
Why not just forbid pathological filenames at the driver level to begin with? Forbid control characters, unprintable characters and filenames starting with a hyphen.
Scripts which use null-delimited lists continue to work. Scripts which use a newline-separated list of filenames now work for all files. Scripts cannot be tricked into using a filename as a flag anymore.
Writing robust code becomes easier, and thus, more reliable.
The negatives are what, people can't prank you or maliciously fuck up things anymore? Is that why it's not been implemented yet? If so that's a stupid reason.@flabdablet said:
Doing similar things in cmd requires endless fartarsing about with obscure features known only to those who have tracked them down experimentally, and even then there are cases that simply cannot be handled at all.
Good thing no one is advocating using cmd for anything, then.
-
@blakeyrat said:
In any case, making things pointlessly difficult as a learning exercise is basically the worst idea ever.
Widespread knowledge of slack and careless ways to do things doesn't make doing them the right way any less worthwhile. I can create SQL injection vulnerabilities by writing code that builds SQL commands by concatenating strings; I should use parameterized queries instead. I can write shell scripts that break on unusual filenames in all kinds of interesting ways; I should wrap double-quotes around my parameter expansions instead. Same pattern.
Proposing to make Unix scripting less error-prone by adding post-facto restrictions to allowable filenames on some tiny subset of installed systems strikes me as coming at the thing the wrong way; to me, it looks just as wrong-headed as attempting to make a web page less vulnerable to SQL injection by adding a client-side clbuttic filter on "DROP" and "DELETE". Unix has had permissive filename rules for forty years. Scripting languages have had well-known ways to deal with that for forty years. The horse has long left that barn, and learning to ride it seems a better option to me than changing the paint on the stable door. Are my metaphors mixed enough yet?
@blakeyrat said:
You're missing the point of CADT. The point isn't that it's reinvented (well-- that's half the point I guess), the real point is that it's reinvented without bothering to find whether the reinvention actually fixes any of the problems the old version had.
The point I was trying to draw attention to is that every design involves trade-offs that will strike some users as horrible flaws, and expecting that a new API must always cause less trouble than the "broken" or "buggy" one it replaces is usually quite naive. A new design might well fix some of what was wrong with the old design, but as jwz hints by labelling all the things "version 0.8", it's equally likely to raise a raft of its own new issues.
@blakeyrat said:
Like, if my software is shit, it's ok as long as I'm self-aware that it's shit?
If my software is designed in ways that will make it a poor fit for certain use cases, it's only polite to give potential users a heads-up. Also, in my world, "might surprise or even annoy Blakeyrat" and "shit" don't usually mean the same thing; your expectations about software behaviour strike me as somewhat idiosyncratic and don't align with mine terribly often.
@blakeyrat said:
And of course the concept of "pride" or "craftmanship" never enters into the equation-- ship early! Ship often! Ship broken! Who gives a shit!
That objectionable attitude remains objectionable regardless of OS choice. I have seen no evidence that it's any more prevalent in software that runs on Linux, or even in open source software generally. Your experience might well be different.
-
@flabdablet said:
I can create SQL injection vulnerabilities by writing code that builds SQL commands by concatenating strings; I should use parameterized queries instead. I can write shell scripts that break on unusual filenames in all kinds of interesting ways; I should wrap double-quotes around my parameter expansions instead. Same pattern.
The difference between shell scripts and SQL is that SQL is embedded in other programming languages as strings - there is literally no way for it to be able to tell if a query was made by string concatenation or not, so it has no choice but to run it.
But filename quoting for parameter expansion? It shouldn't even be an issue. The shell is well aware of parameter expansions, and there is no reason for it to require double quotes at all. It could just go "Hey, look at all these different file names that match the pattern. Lets pass them all as separate arguments".
Powershell does it; it's not an impossible task. It's not even hard.@flabdablet said:
Proposing to make Unix scripting less error-prone by adding post-facto restrictions to allowable filenames on some tiny subset of installed systems strikes me as coming at the thing the wrong way; to me, it looks just as wrong-headed as attempting to make a web page less vulnerable to SQL injection by adding a client-side clbuttic filter on "DROP" and "DELETE". Unix has had permissive filename rules for forty years. Scripting languages have had well-known ways to deal with that for forty years. The horse has long left that barn, and learning to ride it seems a better option to me than changing the paint on the stable door. Are my metaphors mixed enough yet?
The horse has a lasso around its neck; It's certainly possible to shove it back in the barn.
And by lasso I mean the fact that many shell scripts already follow the proposed restrictions. Because it is easier.
-
@Salamander said:
@flabdablet said:
Writing scripts that don't break when fed pathological filenames is not only an excellent way to learn how to write robust scripts, but a good opportunity to reflect on and appreciate how much easier it is to do that using a Bourne shell descendant than a CP/M descendant. Bourne shell has quoting mechanisms that are robust enough to stand up to all those edge cases, just by using them the way they were designed to be used.
I'm sure it does. Doesn't make it any less retarded having to use them.I can't really see much merit in that line of reasoning. A tool provides facilities to do a certain thing (in this case, expand a string value inline without further processing) and "having to" use those facilities to do exactly that thing is "retarded"?
What's your position on the provision for creating parameterized SQL statements in every SQL interface library? Is that retarded too? Should we all be doing the presumably non-retarded thing instead, and going with string concatenation to build our SQL statements just because we can?
@Salamander said:
It gets pretty insane when you want to use grep, or worse, sed on a list of filenames.
If you make the invalid-for-forty-years assumption that one raw filename always equals one line of text, then yes, you will occasionally get unexpected results. If you do want a one-name-per-line list, you can run your raw filenames through printf using a %b format to generate that. Which is, incidentally, exactly what the printf utility's %b option is for.
Of course, if you believe that using tools for the jobs they were designed for is "retarded", you might have trouble with this. I guess you could just abandon all pride in craftsmanship and release it early, release it broken, who gives a shit. But you'll annoy Blakey doing that.
-
@Salamander said:
But filename quoting for parameter expansion? It shouldn't even be an issue. The shell is well aware of parameter expansions, and there is no reason for it to require double quotes at all. It could just go "Hey, look at all these different file names that match the pattern. Lets pass them all as separate arguments".
Powershell does it; it's not an impossible task. It's not even hard.In fact, the mechanism that it uses for that (double quotes around variable expansions) is identical to that used in Bourne shell. Does that mean it's "retarded"? I'm confused.
-
OK, so I've been playing with this stuff in a shell, and I find I've earned my clown shoes by speaking rectally. printf %b does the exact opposite of what I've just said it does: it interprets escape sequences, it doesn't emit them. For that you want printf %q which is a bashism and therefore not part of POSIX.
-
@ender said:
@blakeyrat said:
Not anymore. I'm using the chocolatey.org package manager for Windows which eliminates most the exceptios to Windows Update that you mentionWow, what a remarkably sane comment. And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012?
You don't - set it to UTF-8 and be done (unless you're accessing a legacy system).@blakeyrat said:I can guarantee I don't if I'm using Microsoft's RDP.
Not as long as your local keyboard and the server's keyboard layout match. @blakeyrat said:You know what I meant.
No, I actually don't - if I want to update Microsoft's programs, I have to use Microsoft Update (unless I want to update Windows Live stuff, which has it's own updater for some reason; I also pointed out two cases where you will be asked questions in the middle of installing). If I want to update Adobe's programs, I have to use Adobe's updater. Instead of using one command and answering some questions during the install phase, I have to manually run several updaters (and in many cases download and install updates manually).
-
@flabdablet said:
I can't really see much merit in that line of reasoning. A tool provides facilities to do a certain thing (in this case, expand a string value inline without further processing) and "having to" use those facilities to do exactly that thing is "retarded"?
Having to use something when it shouldn't be necessary at all is retarded, yes.
@flabdablet said:
What's your position on the provision for creating parameterized SQL statements in every SQL interface library? Is that retarded too? Should we all be doing the presumably non-retarded thing instead, and going with string concatenation to build our SQL statements just because we can?
Erwhat? At what point did I say string concatenated SQL is a good idea?
It's not, which is why parameterised SQL exists. Depending on the language you are using, they can even be simpler than escaped-and-concatenated SQL.
Simpler and more reliable. Unlike unix filenames.
-
@flabdablet said:
In fact, the mechanism that it uses for that (double quotes around variable expansions) is identical to that used in Bourne shell. Does that mean it's "retarded"? I'm confused.
Nope, I'm the WTF here. I was incorrectly remembering something else.
-
@flabdablet said:
I thought Linux users would not complain and just fix it like a normal Windows user would do: http://www.stardock.com/products/start8/So, imagine for a second that I'm a Windows user, and having taken inspiration from my Linux-desktop using friends I've got my Start menu all nicely organized by functional category instead of the manufacturer or product name folders that the installers create by default, and I like my Start menu and am comfortable with it and I no longer need to waste time looking through it for that app I haven't used for six months because I know where it will be when I need it - and I turn up to work to find that IT has slapped Windows 8 on my workstation and I'm expected to navigate this instead.
It's not OK because if they take my stapler then I'll set the building on fire.
-
@flabdablet said:
Today's Windows users, for example, still remain unable to save a file called aux.doc or use filenames containing : " / \ | ? or *, solely because the CP/M command interpreter and the DOS command interpreters based on it had no reasonable parser and no reasonable filename quoting mechanism.
Reserved filenames never had anything to do with command interpreter - in DOS, these devices were part of the OS (any program that opened file COM1: through the API would access the first serial port), and for backwards compatibility with DOS 1.0, they're still supported. Windows NT doesn't actually have any problems working with a file named AUX - you can easily access it as long as you use the Unicode long form paths (prefix the full pathname with \?\ and use the Unicode versions of the API).
@flabdablet said:Plus, current drive and current directory are separate things in Windows
Not on NT - it only has a concept of current directory, which is a full pathname (includes drive designation). cmd fakes the old behaviour (where each drive had it's own current directory) with environment variables.
-
@flabdablet said:
Widespread knowledge of slack and careless ways to do things doesn't make doing them the right way any less worthwhile. I can create SQL injection vulnerabilities by writing code that builds SQL commands by concatenating strings; I should use parameterized queries instead. I can write shell scripts that break on unusual filenames in all kinds of interesting ways; I should wrap double-quotes around my parameter expansions instead. Same pattern.
This mode of thinking is so wrong, I'm not sure whether to correct or to just add you to the "hopeless" list.
But you have chosen a good metaphor. Composing SQL queries by concatenating strings is a bug. I was going to waffle there, but let's face it: it is a bug. A good programming language/environment will make it practically impossible to so, or make using sprocs or prepared statements so brain-dead simple that no sane person would go back to the concatenation.
Can you still use concatenation? Unfortunately yes-- as someone posted, SQL doesn't know where the query comes from and really has no way of enforcing it. (Of course you could set permissions as such so that the SQL server can only execute sprocs from the app and that would solve the problem. But that requires a developer who isn't a moron.)
Filenames in Linux are much the same way, with one critical exception: the dangerous way of dealing with filenames is by far easier than the correct way. (Assuming the correct way is even possible.) Your premise here is that means Linux scripters are "just that good" that they fix their script to cope with it. You're wrong. What it really means is that Linux scripters and users, by convention, already limit the possible filenames they use. They just as a rule don't start a filename with a dash, and don't insert control characters in the filename.
Take the Blakeyrat Challenge: go find a shell script that operates on a list of files. Any script. Now create a directory full of filenames that contain control characters and start with dash. Does the script work? Try it. I dare you.
Since everybody, by convention, already limits their filenames to only sane names, the OS should just enforce that.
Oh and read that article I linked. It turns out that Linux filenames are SO INSANE that merely printing them to the screen is a potential security vulnerability. This is the thing you're defending.
@flabdablet said:
Proposing to make Unix scripting less error-prone by adding post-facto restrictions to allowable filenames on some tiny subset of installed systems strikes me as coming at the thing the wrong way; to me, it looks just as wrong-headed as attempting to make a web page less vulnerable to SQL injection by adding a client-side clbuttic filter on "DROP" and "DELETE".
Yeay, your "clbuttic" filter is why people make fun of PHP. The question is, why aren't people making fun of Linux?
@flabdablet said:
Unix has had permissive filename rules for forty years.
And it's been a terrible design decision for 40 years. What's your point?
@flabdablet said:
Scripting languages have had well-known ways to deal with that for forty years.
Yes but how many of the scripts on your computer right now are using those "well-known" ways? How do you account for the author of the article I linked, who searched Google for the "well-known ways" and found that many of the resulting pages were wrong?
I actually think you didn't bother reading the link I posted because, man, how could you have read it and come back here with this shit? Believe me he makes a good case.
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html clicky click.
@flabdablet said:
The horse has long left that barn, and learning to ride it seems a better option to me than changing the paint on the stable door.
In other words, "it's broken. We've Always Done It That Way. We don't give a shit about fixing it." The typical Linux attitude.
@flabdablet said:
If my software is designed in ways that will make it a poor fit for certain use cases, it's only polite to give potential users a heads-up. Also, in my world, "might surprise or even annoy Blakeyrat" and "shit" don't usually mean the same thing; your expectations about software behaviour strike me as somewhat idiosyncratic and don't align with mine terribly often.
I expect software to be as bug-free as possible. Why is that weird? Why don't you have the same expectation?
@flabdablet said:
That objectionable attitude remains objectionable regardless of OS choice. I have seen no evidence that it's any more prevalent in software that runs on Linux, or even in open source software generally. Your experience might well be different.
I didn't say otherwise. What's your point?
Oh this is one of those "the aliens from Jupiter were whispering in my brain while I read Blakeyrat's posting, so I'm replying to the aliens instead of the text Blakeyrat wrote" things. Because whatever you're responding to here is something I didn't type.
-
@flabdablet said:
@blakeyrat said:
And exactly right, why should I have to spent a single millisecond thinking about character encoding in 2012? I can guarantee I don't if I'm using Microsoft's RDP.
I can guarantee I don't if I'm using ssh into any Debian or Ubuntu box from any other Debian or Ubuntu or RedHat box too; they and all the terminal emulators packaged for them all use UTF-8 by default.
PuTTY doesn't; for some reason I fail to understand, it defaults to ISO-8859-1. But it's easy enough to set up a PuTTY profile you can use to connect to your Ubuntu server that has the correct encoding selected. If you want, you can also add the -load command line option to the shortcut you use to launch PuTTY, so it comes straight up with the appropriate profile in use.
In any case, blaming "Linux" for a poor choice of default on the part of your preferred Windows-based ssh client seems a little harsh to me.
ISO-8859-1 is a poor choice for an SSH program, since the SSH standard itself (RFC [url=http://www.ietf.org/rfc/rfc4251.txt]4251[/url]) says it passes any status messages back using ISO-10646 UTF-8 by default. Although in the case of status message, the message encoding is also specified.
Having said that, the specification has some really bizarre bits. During the initial connection, protocol names are always transmitted as US-ASCII while usernames are always transmitted as UTF-8. The actual character encoding is supposed to be figured out from the terminal type.
PuTTY passes "xterm" by default. XTerm has supported UTF-8 for well over a decade and uses control characters to switch between ASCII and UTF-8, which PuTTY may not recognize. In other words, it's a poor choice instead of passing an actual emulation type like "vt100" .
-
@Random832 said:
What gets me is the fact that it's âââââââââ instead of ─── - this implies the curses library or equivalent is emitting a cursor positioning sequence for every single character.
No, it implies that it's actually interpreting 8859-1 as meaning 8859-1, in which hex 92 and hex 80 are U+0092 and U+0080 (not printable), as opposed to interpreting it as meaning Windows-Latin-1, where they are changed to U+201D and U+20AC.
-
@flabdablet said:
So, imagine for a second that I'm a Windows user, and having taken inspiration from my Linux-desktop using friends I've got my Start menu all nicely organized by functional category instead of the manufacturer or product name folders that the installers create by default
Wow. You Linux guys sure are full of yourself. I've had my Start Menu arranged like that for about 12 years now (since Windows 2000). And I didn't get the idea from Linux.
-
@El_Heffe said:
Wow. You Linux guys sure are full of yourself. I've had my Start Menu arranged like that for about 12 years now (since Windows 2000). And I didn't get the idea from Linux.
That's long ago enough to make it possible that some freedesktop.org designer got the idea from you. If that's the case, thank you! It's a good one. I've often wished that Windows packages came with the same kind of category-based default menu locations as Debian ones do, because having a sane menu structure maintained automatically is a considerable convenience.
I'm also glad that my hypothetical menu-organizing Windows user has turned out to be a real person, because that gives me the chance to ask you: how would you react to finding that an OS upgrade applied by your IT department had summarily destroyed the work you've put into maintaining your Start menu?
-
@flabdablet said:
Personally, I'd think "Hey, that's probably something they wouldn't just casually get rid of", then I'd go looking to see if it still exists.how would you react to finding that an OS upgrade applied by your IT department had summarily destroyed the work you've put into maintaining your Start menu?
-
@blakeyrat said:
In other words, "it's broken. We've Always Done It That Way. We don't give a shit about fixing it." The typical Linux attitude.
This is the nub of the disagreement we appear to be stuck in right now. You have frequently commented in ways that make it clear that you associate a "don't give a shit" attitude with Linux and/or its users and/or developers. However, I have seen enough "don't give a shit" in a thirty year IT career to be quite convinced that it's not only completely platform-agnostic but completely industry-agnostic.
I agree with you that "don't give a shit" is annoying, and that developers whose output makes it clear that they don't give a shit deserve to be called out for that. However, I am rather less likely than you, it seems, to jump from "this software behaves in ways that annoy me" to "the developer of this software doesn't give a shit". Perhaps they just care more about something else. "Their priorities are not my priorities" and "they don't give a shit" are not, in my world view, equivalent beliefs.
@blakeyrat said:
I expect software to be as bug-free as possible. Why is that weird? Why don't you have the same expectation?
I would naturally like software to be bug-free. I don't expect it to be so in general, because making bug-free software is hard, as is reaching consensus on exactly what software behaviours should be considered bugs in the first place.
When considering entire software ecosystems, which I guess is what we're talking about when we apply loose-fitting labels like "Windows" and "Linux", there are always going to be issues that annoy, and some of those will indeed be due to design decisions made early on. It seems to me that there are three complementary and equally sane responses to that fact. One is to advocate for and/or implement design changes that address the annoyances; another is to accept that they're simply not going to go away any time soon, and work around them; and the third is to move toward doing most of your work within the ecosystem you find least annoying and/or most enjoyable.
I think it's important to realize that the second response does not amount to "not giving a shit".
I also think it's important to ponder the law of unintended consequences, and to allow for the possibility that your suggested fix for any given behaviour that strikes you as a "bug" might well cause more problems for other people than it solves for you. That's a general observation, by the way; I'm not making any claim about whether it applies to the particular case of permissive filename rules in Unix and descendants, or the choice of default character encoding in PuTTY.
@blakeyrat said:
@flabdablet said:
That objectionable attitude remains objectionable regardless of OS choice. I have seen no evidence that it's any more prevalent in software that runs on Linux, or even in open source software generally. Your experience might well be different.
I didn't say otherwise. What's your point?
I refer you to the quote that I opened this response with, and note that the "typical Linux attitude" remark is exactly a statement that the attitude you object to is prevalent in the Linux community, and by implication more prevalent in that community than in others. You didn't say "typical attitude" or "typical developer attitude" or "typical shit developer attitude"; you said "typical Linux attitude". My point is that not giving a shit is not a "typical Linux attitude"; it's an attitude that is regrettably found across humanity in general, and ascribing it to those in one particular community is unwarranted, unfair, insulting and unhelpful.
@blakeyrat said:
Oh this is one of those "the aliens from Jupiter were whispering in my brain while I read Blakeyrat's posting, so I'm replying to the aliens instead of the text Blakeyrat wrote" things. Because whatever you're responding to here is something I didn't type.
it seems to me that when somebody responds to my comments in a way that makes it clear that they've missed the points I was trying to put, then attempting to clarify those points is more helpful than insulting their reading ability. If your aim is to reduce the amount of "don't give a shit" software you encounter, it seems to me that putdowns are counter-productive. They might well entertain you, but they don't actually help.
And with all that out of the way: are you in fact using PuTTY and if so, does choosing UTF-8 as the character encoding for the connection to your Ubuntu server make its screens render properly?
-
@Salamander said:
@flabdablet said:
I can't really see much merit in that line of reasoning. A tool provides facilities to do a certain thing (in this case, expand a string value inline without further processing) and "having to" use those facilities to do exactly that thing is "retarded"?
Having to use something when it shouldn't be necessary at all is retarded, yes.
"Shouldn't be necessary at all" is the thing, though, isn't it? I think there's room for legitimate disagreement here about what should or should not be necessary.
Filenames containing unusual characters only cause trouble in contexts where some other subsystem is built to use those same characters for its own purposes. In the case of the shell, the troublesome characters are those that the shell uses as word delimiters (mainly assorted whitespace). In the case of the terminal, the troublesome characters are those that introduce terminal control sequences (frequently ESC [). In the case of assorted system utilities, the troublesome characters are those that distinguish filename parameters from command options or switches (leading - for Unix, leading / or occasionally - or sometimes the contents of environment variable SWITCHAR for DOS/Windows).
There are two places where this trouble could be prevented: in the filesystem, by making any potentially troublesome character illegal (this is the approach taken by DOS) or in the other subsystems, by providing facilities to escape or quote or otherwise avoid trouble caused by data containing characters with special meaning (this is the approach taken by Unix).
Both approaches have consequences beyond the primary effect of preventing trouble in handling filenames. Putting the responsibility on the filesystem to disallow troublesome characters means that the filesystem needs to know about what any other subsystem might consider troublesome; it also means that system users need to know that stuff too, so that they can avoid creating files with troublesome names. And it's not particularly future-proof, because subsystems introduced after the filesystem's design has solidified might well have trouble with characters that the filesystem still allows. Adding escaping/filtering facilities to the other subsystems introduces the risk that users of those subsystems might fail to use those facilities; this failure mode becomes more likely if the filesystem is known to impose restrictions of its own.
So: where to put the filtering/escaping/preventing/processing and how much of it to do is a legitimate engineering decision, requiring careful consideration. It's not a "no-brainer" choice, and a system whose designers have made different decisions from the one you personally prefer is not automatically "retarded".
Personally, I'm occasionally annoyed by the fact that I can't save a file with a conventionally formatted date embedded in its name (e.g. "The events of 9/11/2001") because the filesystem API reserves "/" for its own purposes; I'd be in favour of fewer restrictions on filenames, not more. But I know perfectly well that this is only a personal preference, and that there are considered engineering tradeoffs behind every feature of every system I ever use, so I just work around it. It's just not the kind of thing that would lead me to believe that the design of the system I'm using has been "broken and wrong" for forty years.
-
Actually, it is a no-brainer. The only things which should already be blocked by the filesystem from the start are control characters. There is no way a user should typically be able to make a filename with control character anyway, and it simplifies logic for all programs built with that filesystem in mind.
It just so happens that doing so has current, tangible benefits.
Forbidding filenames starting with a hyphen is the only change which is because of the state of programs in unix currently; Many of them can interpret filenames as command flags. This is the fault of the shell's design, but it's such a pervasive system that it's certainly worth putting in a filesystem rule solely for it (and only it). It's also easier to restrict it at the filesystem than to fix the shell and all the scripts that the fix breaks.
The main point you are missing is that putting a restriction on filenames means that it's easier to write robust scripts because you don't have to worry about silly things like worrying about whether or not filenames are correctly escaped. Much like why prepared statements are better than escaped-and-concatenated SQL.
By the way, since you seem to know so much about filename escaping, how would I go about adding a folder to my PATH environment variable if the folder's name contains a colon?
-
@blakeyrat said:
@flabdablet said:
Writing scripts that don't break when fed pathological filenames is not only an excellent way to learn how to write robust scripts,
Actually, this guy says it's literally impossible to do in a portable way. He claims it's only possible by going outside of the standard.
The standard he's most likely talking about is POSIX. Most Unix systems have userland tools that extend that standard in various ways. In particular the GNU toolset, which includes the popular bash command shell and forms part of almost every Linux-based software distribution, is widespread enough that considering it the reference implementation of a de facto standard is a reasonable position to take.
Writing robust scripts for bash is certainly easier than for a strictly POSIX-compliant Bourne shell, and bash is widespread enough that such scripts will usually be adequately portable provided they're headed with #!/bin/bash rather than #!/bin/sh (many distros link a non-bash shell to /bin/sh because bash, as noted in the Bugs section of its man page, is relatively slow).
I agree with you that there's a large amount of deployed shell script that would fail in various interesting ways when run against directories containing filenames with embedded newllines. But I have no evidence to suggest that this has practical consequences serious enough to make adding filesystem-level naming restrictions a worthwhile exercise; fixing or replacing affected scripts and/or their interpreters seems to me to be a far safer bet.
-
@flabdablet said:
I agree with you that "don't give a shit" is annoying, and that developers whose output makes it clear that they don't give a shit deserve to be called out for that. However, I am rather less likely than you, it seems, to jump from "this software behaves in ways that annoy me" to "the developer of this software doesn't give a shit". Perhaps they just care more about something else. "Their priorities are not my priorities" and "they don't give a shit" are not, in my world view, equivalent beliefs.
The key thing here is that blakeyrat cannot conceive of anyone who has different values or experiences from him. If something doesn't fit his idea of good, or isn't useful to him, then it is obviously shit and anyone who defends it has bad motives or is just stupid. The world is black and white, and My Little Pony is a show for grown ups to watch when there are no kids around.
@flabdablet said:And with all that out of the way: are you in fact using PuTTY and if so, does choosing UTF-8 as the character encoding for the connection to your Ubuntu server make its screens render properly?
Dude, WTF is wrong with you!? He didn't ask for help. Man, what's wrong with people around here that they won't simply accept the blakeytruth and move on?
-
@Salamander said:
The main point you are missing is that putting a restriction on filenames means that it's easier to write robust scripts because you don't have to worry about silly things like worrying about whether or not filenames are correctly escaped. Much like why prepared statements are better than escaped-and-concatenated SQL.
The fact that filename restrictions would eliminate certain kinds of script breakage is not in dispute; that's obviously true. What I don't think is anywhere near as obvious is whether, given the state of the Unix ecosystem as it is today, the benefits of doing that now would outweigh the costs. Filesystem design is a pretty fundamental thing, and ease of writing correct scripts is but one of many considerations; fiddling about with the foundations is not something to be taken lightly.
I'm also not sure that my SQL analogy was clear enough. What I was trying to say is that there are quick and dirty ways of preparing SQL queries that break for certain query content, just as there are quick and dirty ways of writing shell script that break for certain filenames; there are also correct, injection-proof ways of preparing SQL queries, just as there are correct, content-insensitive ways of working with shell variables. The fact that SQL queries can contain data values with arbitrary content is not generally considered a WTF, and neither are the need to use prepared statements to deal with that fact or the existence of facilities that make that possible. The case of pathnames with arbitrary content in shell variables seems parallel to me, and I can see no reason why the need to exercise care there should be any more of a WTF than the need to exercise care when building SQL queries.
@Salamander said:
By the way, since you seem to know so much about filename escaping, how would I go about adding a folder to my PATH environment variable if the folder's name contains a colon?
As far as I know, PATH parsing is pretty simple-minded and doesn't allow for any escaping of the embedded pathnames or their separating colons. As a workaround, try creating a symlink (with a pathname that does not contain a colon) to the target directory, then adding the symlink's pathname to PATH.
-
@boomzilla said:
The key thing here is that blakeyrat cannot conceive of anyone who has different values or experiences from him. If something doesn't fit his idea of good, or isn't useful to him, then it is obviously shit and anyone who defends it has bad motives or is just stupid. The world is black and white, and My Little Pony is a show for grown ups to watch when there are no kids around.
His comments certainly give that impression. I am interested in finding out whether there's an interesting mind behind all the sturm und drang; I suspect there is.
@boomzilla said:
Dude, WTF is wrong with you!? He didn't ask for help. Man, what's wrong with people around here that they won't simply accept the blakeytruth and move on?
My shoes are large and render movement awkward.
-
@flabdablet said:
I am interested in finding out whether there's an interesting mind behind all the sturm und drang;
Our house Karkat is entirely comprised of ponies down to the molecular level.
@boomzilla said:
My Little Pony is a show for grown ups to watch when there are no kids around.
True. What is your point?
-
@dhromed said:
@boomzilla said:
My Little Pony is a show for grown ups to watch when there are no kids around.
True. What is your point?I was simply illustrating this site's greatest active troll. You are free to draw any conclusion you like.
-
@dhromed said:
Our house Karkat is entirely comprised of ponies down to the molecular level.
Some interesting artifacts emerge at high magnification.
-
@El_Heffe said:
How did you get all the software to organise it's Start menu entries like this automatically? What's that, you had to manually organise your menu items until they made sense? I see...@flabdablet said:
So, imagine for a second that I'm a Windows user, and having taken inspiration from my Linux-desktop using friends I've got my Start menu all nicely organized by functional category instead of the manufacturer or product name folders that the installers create by default
Wow. You Linux guys sure are full of yourself. I've had my Start Menu arranged like that for about 12 years now (since Windows 2000). And I didn't get the idea from Linux.
-
There's too much text in here for me to give a shit about. Some stuff:
1) Filenames: someone give me one, just ONE, good reason filenames should be able to contain non-printable characters
2) Permissive filenames: yeah it's a bitch that you can't just put a date like 1/1/1970 into a filename, this is because some many assholes love the fucking CLI so much and it sucks shit. Mac Classic, which I remind you had no CLI, allowed any printable character except colon. Any.
3) Anybody who thinks adults can't enjoy My Little Ponies: Friendship is Magic hasn't watched it.
Oh.
And I don't "imply" things. If you come in here and reply to something I "implied", I'm going to get mad at you and call you a dumbshit because if I didn't type it, I didn't say it. You're replying to something from your own brain, you're replying to yourself and claiming I said it. It really pisses me off, it's fucking annoying as hell, and it's a huge obstacle to actually communicating on this forum. So die in a fire.
BTW one of the reasons it's so annoying is because people don't get the concept of "mutual exclusion." Saying "Linux developers are lazy fucks" and saying "Windows developers are lazy fucks" are not mutually-exclusive. So why would you believe that my saying one "implies" I don't believe the other? Idiots.
-
@blakeyrat said:
There's too much text in here for me to give a shit about.
I've read this whole thread and I can't work out if you're trolling the whole forum or if the whole forum is trolling you...
-
@blakeyrat said:
3) Anybody who thinks adults can't enjoy My Little Ponies: Friendship is Magic hasn't watched it.
Reading comprehension: you should try it.
-
@Hmmmm said:
@blakeyrat said:
There's too much text in here for me to give a shit about.
I've read this whole thread and I can't work out if you're trolling the whole forum or if the whole forum is trolling you...I just have a view far outside the IT industry group-think.
-
@blakeyrat said:
Filenames: someone give me one, just ONE, good reason filenames should be able to contain non-printable characters
to give you something to moan about@blakeyrat said:
Mac Classic, which I remind you had no CLI, allowed any printable character except colon. Any.
Permissive filenames: yeah it's a bitch that you can't just put a colon in a filename@blakeyrat said:
Anybody who thinks adults can't enjoy My Little Ponies: Friendship is Magic hasn't watched it.
or has watched it and realises it's for kids, although some of those kids might be a bit on the older side. They're definitely not to be considered adults though.@blakeyrat said:
And I don't "imply" things. If you come in here and reply to something I "implied", I'm going to get mad at you and call you a dumbshit because if I didn't type it, I didn't say it. You're replying to something from your own brain, you're replying to yourself and claiming I said it. It really pisses me off, it's fucking annoying as hell, and it's a huge obstacle to actually communicating on this forum. So die in a fire.
You imply lots of shit. We know it. You know it. Stop trying to convince anyone otherwise, it's an excercise in futility.
-
@blakeyrat said:
I just have a view far outside the IT industry group-think.
I don't think you'll find anyone here disagrees with you there.
-
@Hmmmm said:
I believe the troller usually enjoys the experience and the trollee does not. Although, I am not 100% confident, I would guess that blakeyrat is having a lot less fun with this thread then others.@blakeyrat said:
There's too much text in here for me to give a shit about.
I've read this whole thread and I can't work out if you're trolling the whole forum or if the whole forum is trolling you...
-
@Hmmmm said:
@blakeyrat said:
There's too much text in here for me to give a shit about.
I've read this whole thread and I can't work out if you're trolling the whole forum or if the whole forum is trolling you...
It's definitely both.
EDIT: This is according to my new updated definition of trolling, which doesn't draw any meaningful distinction between trolls and the willfully ignorant.
-
@Rick said:
I believe the troller usually enjoys the experience and the trollee does not. Although, I am not 100% confident, I would guess that blakeyrat is having a lot less fun with this thread then others.
I don't know. I find things like Boomzilla making fun of my reading comprehension in reply to a post where I admitted I didn't read any of the stuff I was replying to hilarious. There's like 3 levels of humor-irony there.
I don't know if anybody else thought it was funny, but whatever, I don't give a shit what you think.
-
@flabdablet said:
Some interesting artifacts emerge at high magnification.
About that video, hulk guy, there's literally another roll right there.
Also the all programs menu hasn't been relevant in Windows for over half a decade except as a searchable index of software on the PC.
-
@blakeyrat said:
I don't know. I find things like Boomzilla making fun of my reading comprehension in reply to a post where I admitted I didn't read any of the stuff I was replying to hilarious. There's like 3 levels of humor-irony there.
My favorite thing in this new post isn't actually your reading comprehension, but your writing incomprehension. In the previous post, you didn't say anything about not reading. Just not giving a shit about. And we all know that My Little Pony doesn't fit into that bucket. For that matter, I almost wonder if you're even capable of comprehending what I wrote to trigger such MLP apathy.
I troll you for my own enjoyment. How can I possibly hope to out troll a person who doesn't even have a clue about the things he just posted about? I don't even want to feign that level of self unawareness.
-
@MiffTheFox said:
About that video, hulk guy, there's literally another roll right there.
What kind of lazy fuck designs a bathroom where the spare roll is behind the user? Typical shitty Linux attitude.
-
@boomzilla said:
zen and the art of TDWTF trolling
That book got kind of weird and stupid at the end.
-
@MiffTheFox said:
Also the all programs menu hasn't been relevant in Windows for over half a decade except as a searchable index of software on the PC.
Wow, that includes Windows 6 AND Windows 6.1! That's two whole minor versions!
-
@Ben L. said:
Wow, that includes Windows 6 AND Windows 6.1! That's two whole minor versions!
Of course. It was introduced in 6.0, which was released in early 2007.
Minor versions in commercial software tend to be much larger milestones then in non-commercial software.
-
@MiffTheFox said:
Minor versions in commercial software tend to be much larger milestones then in non-commercial software.
data or stfu
-
@MiffTheFox said:
Also the all programs menu hasn't been relevant in Windows for over half a decade except as a searchable index of software on the PC.
I know that's how I use recent Windows, but I wonder how true that is across the user base. I'm willing to bet that it's still relevant, given the number of people who are amazed when I tell them about Ctrl-F. Of course, a lot of those have a desktop full of icons, too.
