Linux/Unix/POSIX files

Weng

@blakeyrat said:
Explorer has issues with reparse points.
It doesn't - it's just that the compatibility reparse points in Vista and 7 are specifically crafted so you can't navigate to them (but you can navigate to a directory in them). This is to prevent old backup software from backing up certain things twice

Okay, so there are two solutions that are better than the one that's there:

1) If they have specific backup programs in mind, use the existing compatability layer to manipulate their I/O results.

2) If they're more concerned about generalities, have Explorer not draw the non-navigable reparse points. Unless they're concerned about some fucking backup software that hooks Explorer. Which they should fucking torpedo into total failure-to-function in the compatability layer.

blakeyrat

@dtech said:

My point being that CLI's can really shine in specific situations even if they're about as fast or slower in other situations.

But the situations they shine in are extremely uncommon (like your example). And the situations they're slower in are extremely common (like pretty much what the vast majority of the computer-using public uses their computers for all the time).

So on average you're almost never better-off using the CLI.

The solution (current) is to only use the CLI for those uncommon situations where it's faster, for example, I hate CLIs in general but even I'll break out awk if it's something that warrants it. The solution (ideal) is for GUI applications to be written that can easily accomplish the uncommon situations.

blakeyrat

@Weng said:

1) If they have specific backup programs in mind, use the existing compatability layer to manipulate their I/O results.

Microsoft's compatibility problems aren't due to programs they know, but due to the programs they do not know.

@Weng said:

2) If they're more concerned about generalities, have Explorer not draw the non-navigable reparse points. Unless they're concerned about some fucking backup software that hooks Explorer. Which they should fucking torpedo into total failure-to-function in the compatability layer.

You misunderstand. The two issues here:

1) Reparse points have very specific permissions to avoid breaking backup software
2) Explorer doesn't handle reparse points very well

They are entirely unrelated. Despite ender's strange attempt to imply that they are. Permissions aren't enforced by Explorer.

The only reason problem 2 is being noticed at all right now is that Microsoft started using reparse points in their default configuration, which they haven't done in the past. Explorer has never properly supported reparse points, but did anybody give a crap about it in Windows 2000? Nope.

Sutherlands

@dtech said:

A real-life example that I had to do a few weeks ago: a overview of all mailing lists on a server. This costs me about 30 seconds on the command line (including thinking what I wanted to do):
ls /some/directory/with/mailinglists | mail -s "Mailing list report" someAdress@example.org
Using GUI's this wouldn't have been hard either, but would still take significantly longer: opening an file explorer, copying the list of files, opening your mail app, starting a new mail, pasting it in your mail , sending the mail. You're not telling me that that's faster.

Perhaps, but a GUI could have told you that you spelled the address wrong.

Weng

@blakeyrat said:

The only reason problem 2 is being noticed at all right now is that Microsoft started using reparse points in their default configuration, which they haven't done in the past. Explorer has never properly supported reparse points, but did anybody give a crap about it in Windows 2000? Nope.

Yes, I understand the problem. However, my suggestion still stands - Explorer should not suck at handling reparse points. It should either:

1) Work as a normal person would expect it (which would be precluded by the oddball permissions they have)
2) Be able to detect a reparse point and not present it to the user, because the user can't do anything with it in Explorer anyfuckingway.
3) Be able to look at a reparse point, figure out where it leads, and treat it like a shortcut (which is effectively the same result as #1, but with a subtly different implementation)

I favor #2 as long as the only factory use of reparse points remains compatability.

Zemm

@Sutherlands said:

Perhaps, but a GUI could have told you that you spelled the address wrong.

Biff would let you know pretty quickly about the bounce back.

I often have long-running scripts running in screen, with the final command

echo :) | mail -s "xyz process finished: $SOMETHING" me@example.com

Not sure if this it good or bad but it's what I do! Since the Internet here is only 8000/384 kbps (in theory; it's actually slower) and running rsync uploads can take hours.

pjt33

@blakeyrat said:

@dtech said:
My point being that CLI's can really shine in specific situations even if they're about as fast or slower in other situations.

But the situations they shine in are extremely uncommon (like your example).

Surely CLIs shine in any situation where you want to do the same task repeatably?

serguey123

@pjt33 said:

@blakeyrat said:
@dtech said:
My point being that CLI's can really shine in specific situations even if they're about as fast or slower in other situations.
But the situations they shine in are extremely uncommon (like your example).

Surely CLIs shine in any situation where somebody put a gun to your head and tells you to do the same task repeatably?

FTFY

Noboby wants to be a robot.

btw If the task are that common it is better to script them and then you are only a double click away from freedom to continue to play freecell

Xyro

Oh boy, this topic again.

Okay, here's something I just did like a minute ago: We have a file of data that one of our processes reads. All of a sudden, I needed a small piece of information in the file because I am the admin of this processes and I needed to make sure the data was correct. So, I simply did a "grep data /opt/our/path/data/file" and verified the information lickety split. If I was forced to use a GUI: Bring up an Explorer window, navigate to C:\opt ... find "our", double click ... let it chug on all the stuff we have in "our" ... find "path", double click.. . same with "data" ... double click on "file" ... wait for the text editor to come up... use my superduper leet shortcut of ctrl+f to quickly bring up the find dialog, enter the data, find it. Of course, it could be worse: If we fully embraced the Windows way, we'd have to start regedit ... wait a sec for it to load... okay, now ... is that data in HKLM? I guess so, let's go there.... SOFTWARE... scroll scroll scroll, find our company name, here's the product ... let the tree load for a sec.... okay, now find the data entry... Oh, and don't forget to add a 2 second delay between ever step and mouse movement because this is all on a remote machine and you're forced to pump a whole graphical environment down the network to interact with the system.

I think I'll stick with CLI. And not shoot myself in the foot by creating files with control characters in the name.

(Same reason I don't create files called "nul" and "aux" and "con" in Windows. Except that one time, just to see what would happen. Hint: don't do it, it can hang Explorer and the files are very difficult to delete.)

[url=http://forums.thedailywtf.com/forums/t/16090.aspx]Related thread.[/url]

blakeyrat

@pjt33 said:

@blakeyrat said:
@dtech said:
My point being that CLI's can really shine in specific situations even if they're about as fast or slower in other situations.

But the situations they shine in are extremely uncommon (like your example).

Surely CLIs shine in any situation where you want to do the same task repeatably?

Nothing about that requires a CLI. Well, it kind of does now, because Windows has terrible GUI scripting and Apple stopped giving a fuck entirely... but the point is, Mac Classic didn't even have a CLI, and I had no problems writing scripts for repetitive tasks.

In any case, "do the same task repeatably" is uncommon. So... even if your premise were right, it doesn't apply.

blakeyrat

@Xyro said:

C:\opt

Wrong. Congratulations, your software is already broken on perhaps half of all Windows installs.

@Xyro said:

If we fully embraced the Windows way,

If you fully embraced the Windows way (which doesn't generally involve using the Registry, BTW), your program wouldn't be broken. If you fully embraced the Windows way, and used the Registry, your program would gain remote administration "for free".

CLI or not, you need to NOT be writing Windows software.

And in any case, that still doesn't address any of the points made in this thread, because surely what you're doing is an extremely uncommon operation! Unless everybody in your company has to "make sure the data is correct", in which case your entire workflow is broken in addition to your software being broken.

Xyro

@blakeyrat said:

@Xyro said:
C:\opt

Wrong.

:) I just did that to tease.

@blakeyrat said:

And in any case, that still doesn't address any of the points made in this thread, because surely what you're doing is an extremely uncommon operation!

What I did was an uncommon operation, as is pretty much all the word I do. That's because all the common (read: repetitive) operations are scripted! All my operations are unique snowflakes!

Serious question, so that I have a basis of comparison: What common operation exist in your workflow?

boomzilla

@blakeyrat said:

@pjt33 said:
@blakeyrat said:
@dtech said:
My point being that CLI's can really shine in specific situations even if they're about as fast or slower in other situations.

But the situations they shine in are extremely uncommon (like your example).

Surely CLIs shine in any situation where you want to do the same task repeatably?

In any case, "do the same task repeatably" is uncommon. So... even if your premise were right, it doesn't apply.

What the hell are you saying here? Because it sounds like you're dismissing him just because you want to. Or maybe you never have to repeat anything? Or the letters CLI just drive you into a flaming trolling rage?

Sutherlands

@Xyro said:

Okay, here's something I just did like a minute ago: We have a file of data that one of our processes reads. All of a sudden, I needed a small piece of information in the file because I am the admin of this processes and I needed to make sure the data was correct. So, I simply did a "grep data /opt/our/path/data/file" and verified the information lickety split. If I was forced to use a GUI: Bring up an Explorer window, navigate to C:\opt ... find "our", double click ... let it chug on all the stuff we have in "our" ... find "path", double click.. . same with "data" ... double click on "file" ... wait for the text editor to come up... use my superduper leet shortcut of ctrl+f to quickly bring up the find dialog, enter the data, find it. Of course, it could be worse: If we fully embraced the Windows way, we'd have to start regedit ... wait a sec for it to load... okay, now ... is that data in HKLM? I guess so, let's go there.... SOFTWARE... scroll scroll scroll, find our company name, here's the product ... let the tree load for a sec.... okay, now find the data entry... Oh, and don't forget to add a 2 second delay between ever step and mouse movement because this is all on a remote machine and you're forced to pump a whole graphical environment down the network to interact with the system.

Wait... you use the mouse to navigate through explorer? Well, there's (one of) your problem(s). In order for me to navigate to such a directory, which I do every day looking at various logs or what-not, simply type the first few characters of the directory name and hit enter. Same as typing the first few characters and hitting tab.

Really? The mouse?

ender

@Weng said:

1) If they have specific backup programs in mind, use the existing compatability layer to manipulate their I/O results.

They don't - there's a lot of backup "programs" out there that are simply batch file with xcopy or something similar.@Weng said:

2) If they're more concerned about generalities, have Explorer not draw the non-navigable reparse points. Unless they're concerned about some fucking backup software that hooks Explorer. Which they should fucking torpedo into total failure-to-function in the compatability layer.

Explorer doesn't draw them by default, since they're hidden. However, there's another reason they need to be non-navigatable: the compatibility reparse points create at least 1 loop in the filesystem - you can test this by going to C:\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Microsoft. This would trip any program that does recursive search on disk.

smbarbour

@boomzilla said:

@blakeyrat said:
Roaming is where you put stuff that should be roamed, whether or not roaming profiles is turned on or not.

I guess the question (TRWTF?) is why it's even there at all, since presumably there's no way to even turn it on in Home Premium.

Sure there is... It's called "Anytime Upgrade"

ender

@Weng said:

1) Work as a normal person would expect it (which would be precluded by the oddball permissions they have)
2) Be able to detect a reparse point and not present it to the user, because the user can't do anything with it in Explorer anyfuckingway

I believe Explorer already does that:

What more would you want from it?

dohpaz42

@Mo6eB said:

So BASH is TRWTF. I agree 100% and you really really really shouldn't use it unless you KNOW your filenames won't contain anything more exotic than spaces. Fortunately, we have alternatives like perl, python, ruby, php and others I forget - all languages that do not rely on function output automatically being interpreted as program source code. For every posix shell tool there's an analogous function in your favourite non-crap programming language to do the job without caveats.

The answer to every "how do I ... in bash correctly", is simply "DO NOT FUCKING USE FUCKING BASH!"

Sure, hyphens in filenames are a bit of a pain. Bash, like any other shell/software, is not perfect. But I don't see a problem with using it with things "more exotic than spaces":

user@host:~$ touch "قوال إسلامية, اقوال السنة , اقوال السلف,اقوال المسلمي.txt"
user@host:~$ ls -lh قوال\ إسلامية\,\ اقوال\ السنة\ \,\ اقوال\ السلف\,اقوال\ المسلمي.txt 
-rw-r--r-- 1 user users 0 2011-08-11 14:23 قوال إسلامية, اقوال السنة , اقوال السلف,اقوال المسلمي.txt
user@host:~$ rm -f قوال\ إسلامية\,\ اقوال\ السنة\ \,\ اقوال\ السلف\,اقوال\ المسلمي.txt 
user@host:~$ ls -lh قوال\ إسلامية\,\ اقوال\ السنة\ \,\ اقوال\ السلف\,اقوال\ المسلمي.txt 
ls: cannot access قوال إسلامية, اقوال السنة , اقوال السلف,اقوال المسلمي.txt: No such file or directory
user@host:~$ $SHELL --version
GNU bash, version 4.1.5(1)-release (i686-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I copied and pasted that text from an internet search in the Arabic language - I don't know of a language more "exotic" than that. Additionally, I <3 bash's tab completion, which will properly escape characters that need escaping for you.

While we're on the subject of poorly-named files, the only time that I've ever seen anything like a hyphen at the beginning of a file was when the person was trying to "sort" their directory to keep certain files near the top. That to me is TRWTF, in that it's a workflow issue, and not a shell issue. It would work just as well with numbers and underscores; neither of which cause any problems for programs.

You know that saying, a good carpenter doesn't blame his tools or some such. The same applies here too. Bitch all you want about the CLI/POSIX standard; you'll get about as far as you would trying to argue which religion is better (yes, we all know: you're religion is better... blah blah blah).

Xyro

@Sutherlands said:

Wait... you use the mouse to navigate through explorer?

See, I didn't want to catch flack from blakeyrat:
@blakeyrat said:

Well the solution to that is to stop typing in paths manually. Ever.

Sutherlands

@Xyro said:

@Sutherlands said:
Wait... you use the mouse to navigate through explorer?
See, I didn't want to catch flack from blakeyrat: @blakeyrat said:
Well the solution to that is to stop typing in paths manually. Ever.

There's a difference between using the explorer gui to type a few letters and navigate to the correct folder, and typing in the path manually.

Xyro

@Sutherlands said:

@Xyro said:
@Sutherlands said:
Wait... you use the mouse to navigate through explorer?
See, I didn't want to catch flack from blakeyrat: @blakeyrat said:
Well the solution to that is to stop typing in paths manually. Ever.
There's a difference between using the explorer gui to type a few letters and navigate to the correct folder, and typing in the path manually.

Then I guess I don't understand his point, because the same can be said about tab-completion in Bash and other nice shells.

FWIW, I don't mouse around in Explorer (or anything else) all that often, only when I'm feeling lazy and have my other hand propping up my head. Instead of typing the characters in the path, however, I usually just type them into the main file display area. However x2, I have all of my frequently-used paths in the Run history and just select them from there. I try to avoid Explorer when possible.

serguey123

@Xyro said:

FWIW, I don't mouse around in Explorer (or anything else) all that often, only when I'm feeling lazy and have my other hand propping up my head.

Ohh, kinky

Is that how we call it nowaday?

too_many_usernames

@ender said:

AFAIK, one of the reasons was that programs were hitting the MAX_PATH limit.

The guy who sits next to me in here in the office has a giant (200MB or so) folder on his computer (XP - yes, my company has not upgraded) that Windows won't let him delete because it's "path is too long".

I'm trying to figure out how the thing can be created with too long a filename but not deleted.

(And yes, I know there is a way to delete this. But it requires use of the command line unless you want to go find some third-party GUI app to do it. Why Explorer doesn't have this capability is baffling.)

blakeyrat

@too_many_usernames said:

I'm trying to figure out how the thing can be created with too long a filename but not deleted.

They were created using relative paths. Deleting requires absolute paths.

@too_many_usernames said:

(And yes, I know there is a way to delete this. But it requires use of the command line unless you want to go find some third-party GUI app to do it. Why Explorer doesn't have this capability is baffling.)

There's a workaround you can do in Explorer: rename parent folders to "a" until the path is short enough to delete, then rename them back when done. Doesn't require use of the CLI, or anything other than Explorer itself... it's just not automatic, and a hassle.

But yes, this is definitely a problem in Explorer.

Daniel_Beardsmore

@blakeyrat said:

So on average you're almost never better-off using the CLI.

I wish someone had told the Exchange team that before Exchange 2007 came out …

roelforg

RTFM!!!

Just escape the space (or any special char ftm) with a backspace!!!

Jeah, when you mean "cat, open and print the content of file /path/with spaces/file.txt" and issue:

[code]

cat /path/with spaces/files.txt

[/code]

cat receives (due to the shell parsing the space as a arg. seperator): "cat, open and print the contents of files /path/with and spaces/file.txt"

What you're meaning can be achived like this (either like will do):

[code]

cat "/path/with spaces/file.txt"

cat /path/with\ spaces/file.txt

[/code]

I mean: STFU and RTFM before flaming and (blakey)ranting!!!

EDIT:

CS got me! It added in the code blocks! How do i fix this? (seriously, the editor and the bbcode don't get along well)

blakeyrat

Are you some kind of Linux clown?

lettucemode

@roelforg said:

RTFM!!!
Just escape the space (or any special char ftm) with a backspace!!!
Jeah, when you mean "cat, open and print the content of file /path/with spaces/file.txt" and issue:
cat /path/with spaces/files.txt
cat receives (due to the shell parsing the space as a arg. seperator): "cat, open and print the contents of files /path/with and spaces/file.txt"
What you're meaning can be achived like this (either like will do):
cat "/path/with spaces/file.txt"cat /path/with spaces/file.txt
I mean: STFU and RTFM before flaming and (blakey)ranting!!!
EDIT:
CS got me! It added in the code blocks! How do i fix this? (seriously, the editor and the bbcode don't get along well)

I don't understand a word you just said

blakeyrat

@lettucemode said:

I don't understand a word you just said

You think that's bad? Try <a href="http://forums.thedailywtf.com/forums/p/24703/281592.aspx#281592>this one.

morbiuswilters

@roelforg said:

RTFM!!!
Just escape the space (or any special char ftm) with a backspace!!!
Jeah, when you mean "cat, open and print the content of file /path/with spaces/file.txt" and issue:
cat /path/with spaces/files.txt
cat receives (due to the shell parsing the space as a arg. seperator): "cat, open and print the contents of files /path/with and spaces/file.txt"
What you're meaning can be achived like this (either like will do):
cat "/path/with spaces/file.txt"cat /path/with spaces/file.txt
I mean: STFU and RTFM before flaming and (blakey)ranting!!!
EDIT:
CS got me! It added in the code blocks! How do i fix this? (seriously, the editor and the bbcode don't get along well)

You are so terribly, terribly wrong. You didn't even read the OP. Linux filename handling is bad. Period.