🐧 Lunix

Buddy

a) normally I don't write URLs. Non-crappy systems can usually get by with just the domain and path.
b) more to the point, that is strictly worse behavior you're talking about adopting there. Your camel_cased or underScored or justplainfucked filenames are a pain in the ass and totally don't justify setting the word 'my’ in bold like that.

Masaaki_Hosoi

@Buddy said:

a) normally I don't write URLs. Non-crappy systems can usually get by with just the domain and path.
b) more to the point, that is strictly worse behavior you're talking about adopting there. Your camel_cased or underScored or justplainfucked filenames are a pain in the ass and totally don't justify setting the word 'my’ in bold like that.

To be fair, even on Windows I have a habit of using underscores instead of spaces, and I'm pretty sure that habit came from programming. Still, every so often I use spaces myself (often when I remember "oh yeah, this isn't a variable name, I can use spaces"), and VERY frequently download files which contain spaces.

PleegWat

@riking said:

```
rm ls (gl ./*.txt) ./README


You just know that they would abbreviate as much as possible.</blockquote>

And I think that would be fine - though I disagree with your chosen route. `rm ls` like this is ambiguous unless `rm` only ever has one argument. This is false, as it also takes options. Better would be the current situation where it takes mutiple arguments, each of which can be a file or list of files to delete.

rm (gl ./*.txt) ./README


I think in almost all cases brackets to identify a new function call should not be optional.

boomzilla

@blakeyrat said:

So let me get this straight:

Linux is great because people have to learn (by error, presumably) that spaces in filenames are trouble and avoid them? Even though it allows spaces in filenames. And if the user wants to use a space, well, then FUCK THEM!

Compelling argument.

Your nonsense is just like the other guy bitching about the MAX_PATH problem and then other people telling him that it's super fucking rare and no one really needs to bother with it.

boomzilla

@dkf said:

It's usually expressed in terms of “We don't want to break existing code.”

Sorry, that excuse isn't compatible with Lunix hardware.

boomzilla

@Onyx said:

@blakeyrat said:
...

I'm a special snowflake who wanted to run Cinnamon on Debian which is not the official way it's distributed. What would you do?

He would update his preferences based on whatever the fashion experts at MS decreed was the new black, just like he always does. Then he'd excoriate anyone who disagreed as Luddites who can't handle any change.

blakeyrat

@anonymous234 said:

I was actually thinking of JSON as the simplest way you could implement objects through Linux pipes...

Ok; I want to pipe an image. Now I want to pipe a sound sample.

JSON is still a text-based format. NOT EVERYTHING IS FUCKING TEXT. In fact, very few things people actually care about are text or even representable as text.

blakeyrat

@boomzilla said:

Your nonsense is just like the other guy bitching about the MAX_PATH problem and then other people telling him that it's super fucking rare and no one really needs to bother with it.

It's "super fucking rare" for someone to want to put a space in their filename? What planet do you live on, exactly? Because it ain't Earth.

PleegWat

Taking into account backwards compatibility, I think the best way to go with pipes is supporting some side-channel mechanism to provide a mime-type.

boomzilla

@blakeyrat said:

It's "super fucking rare" for someone to want to put a space in their filename?

No, the point was that the problem is getting blown out of proportion. Or not. And then someone else going in the opposite "direction."

NB: the quotes there are meant to convey that I wasn't meaning a literal, physical direction.

blakeyrat

@boomzilla said:

No, the point was that the problem is getting blown out of proportion.

Well we'll just have to disagree about that.

The OS says spaces in filenames are perfectly ok. Adding one gives you no warnings or errors. Virtually every tool in the OS breaks if spaces in filenames are present.

To me, that's a Big Fucking Deal. That's a "what is wrong with the idiots who designed this?" Big Fucking Deal. That's a "why the fuck are otherwise-intelligent people actually choosing this OS?" Big Fucking Deal.

flabdablet

@boomzilla said:

Your nonsense

I'd just like to point out, gently, that you are now arguing with blakeyrat, in a thread started by blakeyrat about Linux, and offer you a slightly less painful alternative implement for smashing repeatedly into your own forehead on the off-chance you'd prefer that.
https://ecowomen.files.wordpress.com/2010/05/cast_iron_frying_pan.jpg

boomzilla

@blakeyrat said:

The OS says spaces in filenames are perfectly ok. Adding one gives you no warnings or errors. Virtually every tool in the OS breaks if spaces in filenames are present.

Just like every other operating system?

@blakeyrat said:

To me, that's a Big Fucking Deal.

But...the point is that normally people deal with it and it doesn't actually cause problems most of the time. It's a PITA, but not a catastrophe, practically speaking.

@flabdablet said:

I'd just like to point out,

I know. I'm indulging a bit now that we're past Easter. Please forgive me.

blakeyrat

@boomzilla said:

Just like every other operating system?

Nope. And stop posting ridiculous and wrong things you idiot.

@boomzilla said:

But...the point is that normally people deal with it and it doesn't actually cause problems most of the time. It's a PITA, but not a catastrophe, practically speaking.

Why don't they fix it, then people wouldn't have to deal with it? And maybe working with their shitty computers would be a little more pleasant?

boomzilla

@blakeyrat said:

Nope. And stop posting ridiculous and wrong things you idiot.

Huh?

I should stop now, I think we've reached peak makes-no-sense.

blakeyrat

The only applications on Windows that break when you use spaces in filenames are those "ported" from Linux.

flabdablet

@boomzilla said:

Just like every other operating system?

This is where you're wrong, see. Properly designed systems have cunning mechanisms in place to work around the problem.

CreateProcess:

The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

c:\program.exe files\sub dir\program name
c:\program files\sub.exe dir\program name
c:\program files\sub dir\program.exe name
c:\program files\sub dir\program name.exe

And of course it goes without saying that these mechanisms are built into system calls, not limited to the shell, so that any application program can take advantage of them without even needing to use the shell. How cool is that?

boomzilla

Heh...thanks for making this thread funny. It is a comedy site, after all.

blakeyrat

You're welcome, go suck a cock.

TwelveBaud

Linux applications have had their arguments spoon-fed them by the shell, all nicely expanded and prettified and escape-character-stripped and digested into easily-used pap.

Windows applications got handed one string in their PEB. "Here's your command line, have fun! And don't come crying to me if it's not what you expected. You wanna know how long it is? Fuck you, it's bite-me characters long."

Thus, Windows applications know how to deal with a command line: it's sink-or-swim, and they swam. Linux apps just aren't cut out for Windows' rough-and-tumble world.

PleegWat

Looks at his TV series collection

TV Series/Doctor Who/Season 1/01 - Rose.avi

Works fine... never had a problem with it. Either OS.

dkf

@TwelveBaud said:

Windows applications got handed one string in their PEB. "Here's your command line, have fun! And don't come crying to me if it's not what you expected. You wanna know how long it is? Fuck you, it's bite-me characters long."

This is usually handled by the runtime library that the Windows application was linked again. Unfortunately, there's quite a few different RTLs about, and they all deal with this sort of thing differently. Because consistency would be contrary to user expectations…

antiquarian

@boomzilla said:

I know. I'm indulging a bit now that we're past Easter. Please forgive me.

Did you give up blakeybaiting for Lent?

Jarry

my VS2010 broke hard when i had a space in a project path.
and AFAIK VS isn't "ported" from linux

EvanED

@anonymous234 said:

I was actually thinking of JSON as the simplest way you could implement objects through Linux pipes...

This is actually what the tools I'm building are built around. It's not without its drawbacks, but I think the idea presents a ton of advantages.

The one thing to be careful of is that you don't want the whole pipe to be a single JSON object, because the ability to do streaming is an important part of pipes. So you don't want dir to output [ {"name": "file1"}, {"name": "file2"}, ...], you want it to output just {"name":"file1"} {"name":"file2"} (no [] or ,).

(Really there are a few other fields associated with a file, which was the purpose of my library for iterating directory contents, but I trimmed them for illustration purposes.)

@Eldelshell said:

You're doing that every day you write a URL, when sending an email, when writing code and even by looking at a screen for 8 straight hours.

Like Buddy, I rarely type URLs, and even if I did it wouldn't be a great argument because you can type spaces into the URL just fine and the browser will turn it into the right thing behind the scenes for you. Similar for emails: I can type "John Doe" into the address field if I want and it will do the right thing if they are in my address book.

Code is the one "good" counterargument, but I think there are important differences. The main one is that I don't think there's a clear path to how you could make spaces work in most languages; there would be too many syntactic ambiguities. By contrast, file names with spaces work without problem 95% of the time and can me made to work 95% of the rest of the time; we're close to having a solution. And there are clear ways for how you could increase both of those, it's just that <editorializing>people are too stuck in 1975</editorializing>.

EvanED

@anonymous234 said:

Because Python is a decent language in itself, and is already found on most Linux systems. The problem is its file and process management functions are awkward as fuck. But what if you could do something like

I've thought about that, but I think it would be too hard to work a good interface into the syntax of the language. Like what do I want to do if I want to run foo bar? You can't just say foo bar, you can't just say foo(bar), or even run(foo, bar); the shortest thing I can think of is something like r("foo", "bar"). Now, granted my command names are short, but that's literally more than twice the length of what you could do with a normal shell.

Eldelshell

@EvanED said:

Like Buddy, I rarely type URLs, and even if I did it wouldn't be a great argument because you can type spaces into the URL just fine and the browser will turn it into the right thing behind the scenes for you. Similar for emails: I can type "John Doe" into the address field if I want and it will do the right thing if they are in my address book.

Totally missed the point. I was talking about changing behavior to conform to a system (you have to type www and @) not about spaces specifically.

ben_lubar

You're trying to save less than 10 bytes. That is never a useful cause.

Onyx

@EvanED said:

The one thing to be careful of is that you don't want the whole pipe to be a single JSON object, because the ability to do streaming is an important part of pipes. So you don't want dir to output [ {"name": "file1"}, {"name": "file2"}, ...], you want it to output just {"name":"file1"} {"name":"file2"} (no [] or ,).

I assume you intend to use those objects to relay additional information as well, such as MIME type and possibly full absolute path?

TwelveBaud

@Jarry said:

my VS2010 broke hard when i had a space in a project path.

Then whoever set up your project file is a complete, total, and utter moron. The default project path has spaces!
C:\Documents and Settings<username>\My Documents\Visual Studio 2010\Projects\

EvanED

@ben_lubar said:

You're trying to save less than 10 bytes. That is never a useful cause.

Shells are one of the very few contexts where extreme terseness is a good thing, because by it's nature a large proportion of the "programs" you write will be write-once, run-once. I think in that context, keystrokes do matter, and typability matters. Even if it's not a huge "real" win, it feels like a win, and perception is important too as long is it doesn't come at a significant cost to reality.

Edit: to elaborate a little, even though a lot more time goes into thinking about what to do than actually doing, what I find is that I can't actually do both of those at exactly the same time. So when it comes time to actually run the command, I have to stop thinking at a higher level and think about what I'm actually typing in at a given point in time. So what that means is that when I actually go to enter a command, there's almost a mini context switch as I go from thinking about what I want to do to thinking about "ok now I type --foo". If you can cut the time it takes to actually carry that out, you are shortening the context-switch time. I think that's why it feels faster, but more to the point I think that has real value because it will reduce how much stuff gets evicted from your short-term memory.

@Onyx said:

I assume you intend to use those objects to relay additional information as well, such as MIME type and possibly full absolute path?

My replacement for ls reports the information it is able to get about the files without performing a stat. The most useful piece of information is what kind of thing the entry names -- regular file, directory, symlink, etc.

So MIME type no, but I think I do put the full path in there. The thing I really wish was available is whether the file has execute permissions, but that requires a stat so you have to perform that separately (for which I have a separate utility that does the anaogue of stat).

Onyx

Maybe it was Linux spaces. You know, the ones you get when using a Linux keyboard.

tarunik

@asdf said:

Also, NTFS isn't much better in this regard. It allows file names which no single tool on Windows will ever be able to do anything with. Once you've managed to create a file with a question mark, colon or quotation mark in its name, you won't even be able to rename it or delete it. Discoursistent!

Yep -- been there (courtesy of the Cygwin SVN client), seen that epic fail.

@Onyx said:

If that was an easy question it would probably already be answered, a solution devised, and we'd laugh about stuff in this thread as a thing those poor wretches in the past had to do.

My personal take? The diversity that exists in the Linux ecosystem is both a blessing and a curse. On one hand, you have a choice of tools, if you're unhappy with one you can seek out another. On the other hand there are so many competing "standards" that picking one over the other is nearly impossible, especially in a community where, due to the nature of open source, everyone has a say. Sure, some voices are more important than the others, but still.

Now take PowerShell. If you worked at Microsoft and were asked to build it, right now (in this hypothetical I'm assuming it doesn't exist yet), what would you do? Well, it's a shell for an MS OS, built for power users and programmers who use that OS. What will you pick as a basis of your syntax and workflow? How many MS supported scripting languages you can pick from? 3? JScript, VBScript and .NET family (I am not differentiating between C# and VB in this case), correct? Is it a hard choice, really?

Now try to do that as a Linux OS developer. Pick one. There's Ruby, there's Python, there's Perl, there's fuck knows whatever else. Then try not to lose your community in the process as well. Remember, no matter how big Debian or RHEL are they still depend on a community that contributes to the project. MS has enough paid programmers, and enough users that will stick with their OS either way that they don't have to worry about that. Linux distros usually don't have such luxury.

Yes, it's excuses. No, I don't think that should stop them. But that's the current situation. Hopefully it will get better one day. For now, I can live with bash for basic day-to-day operations and script stuff in something else when going gets tough in bash. And I'll be the first one to throw it in /dev/null the day something better becomes the standard. But for now, bash is ubiquitous and I'll stick to that for scripting because I know it will work on 99.99% of Linux systems I want to use it on.

Besides, Perl and Python are common enough that you can practically consider them ubiquitous on *nix systems -- although I have met an AIX box that was so impoverished that it didn't have bash installed! (I rectified that, with the duly obtained permission of the sysadmin, ofc :) )

@blakeyrat said:

Ok; I want to pipe an image. Now I want to pipe a sound sample.

Pipes are octet transports -- the only thing that has to happen is that the sender and receiver agree on the format. So, I can take sound samples, images, video, or even ELF relocatables and pipe them about just as easily as I can with plain text.

@boomzilla said:

Just like every other operating system?

Like the tools Windows inherited from DOS handle spaces in filenames by default...

blakeyrat

@Jarry said:

my VS2010 broke hard when i had a space in a project path

Lies.

Jarry

might be. but as i recall, the default path uses something like c:\\%user_data%/%VS2010projects%

the point stands, a windows program breaks when you give it spaces. i'll look into it when i'm home to see if i can repro it, to have something more apart from me saying it breaks

Jarry

i have no need to lie. VS is the best ide out there, yet it broke when the path was something like C:\\my super duper project

blakeyrat

Liar.

boomzilla

Lyre

PleegWat

@EvanED said:

My replacement for ls reports the information it is able to get about the files without performing a stat. The most useful piece of information is what kind of thing the entry names -- regular file, directory, symlink, etc.

So MIME type no, but I think I do put the full path in there. The thing I really wish was available is whether the file has execute permissions, but that requires a stat so you have to perform that separately (for which I have a separate utility that does the anaogue of stat).

I suspect your backend (python?) may be fooling you. In the underlying C api, the only thing you get when iterating a directory are entry names, and everything else requires a stat anyway.

TwelveBaud

Probably because, by default, only administrators can write files in directories off the system drive root. This hasn't changed since NT 3.5.

Eldelshell

@tarunik said:

although I have met an AIX box that was so impoverished that it didn't have bash installed!

That's not uncommon if you've been for some time jumping between different UNIX. AFAIR HP/UX used POSIX by default which is quite arcane and Solaris tcsh and Bash was an optional package.

accalia

@asdf said:

Also, NTFS isn't much better in this regard. It allows file names which no single tool on Windows will ever be able to do anything with. Once you've managed to create a file with a question mark, colon or quotation mark in its name, you won't even be able to rename it or delete it. Discoursistent!

even more fun.... manage to get one named CON or LPT1

flabdablet

@EvanED said:

You can't just say foo bar, you can't just say foo(bar), or even run(foo, bar); the shortest thing I can think of is something like r("foo", "bar"). Now, granted my command names are short, but that's literally more than twice the length of what you could do with a normal shell.

This is exactly the problem that every CLI ever invented has had to confront in one way or another. Nice regular consistent machine-parseable syntactic sugar to make it clear what's a string and what's a function call and what's an object is all very well for programming languages, but it's a complete pain in the arse to have to type over and over and over.

Bourne shell and its derivatives have the balance between the competing usability requirements of thing-to-type-commands-into and thing-to-write-small-scripts-in just about exactly right. The fact that writing robust scripts requires slightly more care in Bourne shells than it would in something like Python or VBScript is a consequence of Bourne shell's not having been designed solely as a scripting language.

As for text pipelines vs. object pipelines: I remain unconvinced that the stream-of-objects data structure is so much more useful than the collection-of-objects data structure as to warrant basing a scripting language around it. I have yet to see anything written in PowerShell that would have taken more effort to write or more effort to comprehend than an equivalent in VBScript.

Yes, ad-hoc text serdes for IPC is pure overhead and often done annoyingly badly besides. But for debugging scripts, the ability to stick a tee /tmp/logfile anywhere in a Bourne shell pipeline and use ordinary text manipulation tools to examine the data flowing down the pipe at that point is absolutely invaluable, and simple character-delimited text formats are consistently easier to parse by eye than JSON, XML and so forth.

I have worked with many, many command line interfaces, and Bourne shell derivatives remain the ones I consistently wish more of the others would resemble better. Not because the syntax is super-clean (it isn't: for i in "${!list[@]}" wtf?) but because all those shells do a very good job of making easy things really easy and hard things possible.

That said: once a script written in any CLI's native command language has grown to more than a couple hundred lines, it's a good candidate for rewriting in something cleaner.

EvanED

@PleegWat said:

I suspect your backend (python?) may be fooling you. In the underlying C api, the only thing you get when iterating a directory are entry names, and everything else requires a stat anyway.

That's all POSIX guarantees, but in practice that's not all you get; in fact, the reason I wrote the library I mentioned (in addition to another reason) was exactly so that I could get that extra information.

On Linux, the dirent structure is defined as follows:

       struct dirent {
           ino_t          d_ino;       /* inode number */
           off_t          d_off;       /* not an offset; see NOTES */
           unsigned short d_reclen;    /* length of this record */
           unsigned char  d_type;      /* type of file; not supported
                                          by all filesystem types */
           char           d_name[256]; /* filename */
       };

The only fields in the dirent structure that are mandated by POSIX.1 are: d_name[], of unspecified size, with at most NAME_MAX characters preceding the terminating null byte ('\0'); and (as an XSI extension) d_ino. The other fields are unstandardized, and not present on all systems; see NOTES below for some further details.
...

Currently, only some filesystems (among them: Btrfs, ext2, ext3, and ext4) have full support for returning the file type in d_type. All applications must properly handle a return of DT_UNKNOWN.

(That should all be one quote, from man readdir, but Discourse.)

(The other reason for my library was so that it could return file names immediately, without first building the full list.)

Jarry

once again, it fixed when the path was changed to C\\my_super_duper_project
nothing else was changed. i'm not saying it was set right or that i knew what i was doing.

flabdablet

@tarunik said:

Pipes are octet transports -- the only thing that has to happen is that the sender and receiver agree on the format.

The other thing that has to happen is that receivers need to handle the case of incomplete messages, since the pipe itself has no notion of message boundaries.

boomzilla

@Jarry said:

i'm not saying it was set right or that i knew what i was doing.

Well, hey, we know that programming shouldn't just be for people who know what they're doing. SPANK, SPANK, Windows!

EvanED

I don't know what went wrong for you, but it almost certainly wasn't spaces, because VS deals with spaces in filenames just fine. Hell, it defaults to putting things into My Documents/Visual Studio Projects/... by default!

Eldelshell

Maybe he's running VS in Wine?

xaade

@blakeyrat said:

"everything's text".

@blakeyrat said:

allowing virtually any character

Ah, the freedom of open source.