Go, Go, Gadget Depends!

ben_lubar

Okay, let's assume that the $PATH environment variable is magical now and you can store an array in it instead of a colon-delimited string.

Environment variables are passed to programs after their arguments. You can verify this with this program:

#include <stdio.h>

int main(int argc, const char *argv[]) {
        int i;

        for (i = argc + 1; argv[i]; ++i) {
                printf("%s\n", argv[i]);
        }
}

Please explain how you would store an array in there.

ben_lubar

@blakeyrat said:

end up in a different location

What if I add a second hard drive and name it Freddy? Does it still consider those two paths to be the same location?

inode - Wikipedia

blakeyrat

@ben_lubar said:

What if I add a second hard drive and name it Freddy?

What do you mean? Nothing happens. I guess? Is that the answer you're looking for?

You just have two hard drives named Freddy. It's not even hard to tell them apart, since Mac Classic had a proper spatial GUI.

@ben_lubar said:

Does it still consider those two paths to be the same location?

The point is, files in Mac Classic don't (for all practical purposes) have paths. The user never types in a path. A program should never need to treat a path as text. There's no such thing as paths.

(There is such a thing as paths; for compatibility with ported programs there actually was a way to look a file up by its path. But if you ever showed the path to the user, or even worse made the user type it in, you'd be fucking shanked.)

Files are identified by their handles, which the OS gives you when you open one.

One of the huge annoyances when I first switched to Windows is this horrible buggy behavior:

Open a file named foo.txt
Edit the file's contents
Rename the file (in Explorer) to bar.txt
Save the file

This results in TWO FILES! WTF KIND OF DEMENTED WRONG THINKING MAKES THIS BROKEN SHIT ACCEPTABLE!?

Anyway, that was one of the many shocks I received when I moved from an OS that was actually designed from scratch by intelligent people to one that was just glommed-together with decades of bullshit. Now the only OSes available for sale are the glommed-together kind.

What a great industry.

MathNerdCNU

Was Mac Classic any way *nix related? From what I recall Classic Mac was whatever Jobs and crew ~~were inspired by~~stole after visiting Xerox PARC.

MathNerdCNU

So your complaint is a text editor keeps data contents in MEMORY and doesn't lock the file? That's fucking dumb. Your complaint, not the editor behavior.

blakeyrat

@MathNerdCNU said:

So your complaint is a text editor keeps data contents in MEMORY and doesn't lock the file?

No.

My complaint is that renaming a file that's open doesn't actually rename the file. What it does instead is delete the old file and create a new one with a new name. The way you tell this is what happens is that saving the file in the editor re-creates the original file.

@MathNerdCNU said:

That's fucking dumb.

No it's not. The file's name is meta-data. Changing the name shouldn't move the file, that makes no fucking sense.

If changing the "Last Modified" date resulted in broken behavior like this, you wouldn't be defending it.

@MathNerdCNU said:

Your complaint, not the editor behavior.

Why did the editor write a new file when I was trying to save the original file? Whether it's the editor's fault or the OS' fault, this is so clearly a bug I can't even imagine a defense of it.

dse

I think the text editor does not keep an open handle to the file, so in a sense it is not open (opens the file reads content to memory then closes the file, then when you save it just creates a file with name in the caption). Instead try opening it with a proper hex editor (one that maps the file to memory), that might actually do what you want, but I am not sure, just curious. Next time I run Windows will test it.

blakeyrat

Like I said, regardless of whether it's Windows' bug or the application's, the behavior is ENDEMIC in Windows and it's fucking broken as shit.

MathNerdCNU

@blakeyrat said:

My complaint is that renaming a file that's open doesn't actually rename the file. What it does instead is delete the old file and create a new one with a new name. The way you tell this is what happens is that saving the file in the editor re-creates the original file.

If you want to make sure a file doesn't rename outside the scope of the editor, write one that takes a LOCK on the fucking file. Don't act stupid because that's how naive text editors have worked for 30 years.

@blakeyrat said:

No it's not. The file's name is meta-data. Changing the name shouldn't move the file, that makes no fucking sense.

If changing the "Last Modified" date resulted in broken behavior like this, you wouldn't be defending it.

The file name + path is the human readable identifier. Intrinsic to the FILE. Not data ABOUT the file.

@blakeyrat said:

Why did the editor write a new file when I was trying to save the original file? Whether it's the editor's fault or the OS' fault, this is so clearly a bug I can't even imagine a defense of it.

Because software didn't lock the file. This is not a bug, this is a feature. Want to ensure changes don't get made under you? LOCK THE FILE.

cartman82

@ben_lubar said:

Well, $GOPATH is parsed the same way that $PATH is, so you're free to make as many roots for your code as you want.

And then you get a fun guessing game, called "where did this particular library come from?"

@Gaska said:

Dependency hell ahoy!

Indeed. Some googling revealed having more than one thing in GOPATH is a BAD idea.

cartman82

@ben_lubar said:

Environment variables are passed to programs after their arguments. You can verify this with this program:

WTF? I didn't know that. Interesting.

sloosecannon

@blakeyrat said:

My complaint is that renaming a file that's open doesn't actually rename the file. What it does instead is delete the old file and create a new one with a new name. The way you tell this is what happens is that saving the file in the editor re-creates the original file.

No. Changing the file handle would be "dumb" and a bug. CLOSED_WONTFIX_NOTABUG.

Just because you're used to your buggy Mac Classic OS doesn't mean you should force the rest of the world to operate that way too.

ben_lubar

But text editors don't keep a handle to the file they're editing. They usually load the file, remember the path to the file, and then when it's time to save, open, write, and close the file.

If they kept the file open, @blakeyrat wouldn't be able to rename the file because Windows automatically locks files that are in any kind of thing resembling use.

sloosecannon

True... which exemplifies how ridiculous that idea is......

blakeyrat

@sloosecannon said:

True... which exemplifies how ridiculous that idea is......

The idea of correct behavior?

Look, you don't like the Windows behavior because it's correct. You've probably never even thought about it longer than 46 nanoseconds.

You like it because it's what you're used to. Well. You got used to shitty broken behavior. Sorry.

ben_lubar

@blakeyrat said:

it's correct

As opposed to the Linux behavior, which would do what your Mac OS 9 example had that was "correct" before?

blakeyrat

I never said anything about Linux. I don't even know/remember what the Linux behavior is.

Ben L, you're getting as bad as some of the other people here. Son I am disappoint.

ben_lubar

$ touch blakeyrat.txt
$ (sleep 5 && echo "butts") >> blakeyrat.txt & mv blakeyrat.txt fred.txt
$ cat fred.txt
butts

blakeyrat

Yeah I don't speak your gibberish moon-language, as you well know.

TwelveBaud

This post is deleted!

blakeyrat

This post is deleted!

FrostCat

@blakeyrat said:

bug

You keep using that word. It doesn't mean what you think it means.

dkf

@MathNerdCNU said:

The file name + path is the human readable identifier. Intrinsic to the FILE. Not data ABOUT the file.

You can tell when a user is really a techie. Techies understand the difference between names and identities. Non-techies conflate the two.

Gąska

@ben_lubar said:

Environment variables are passed to programs after their arguments.

Is it guaranteed by anything? If yes, in what spec is it written?

@ben_lubar said:

Please explain how you would store an array in there.

How do I store an arbitrary object in string array? Well, first thing I'd do is get rid of string array.

dkf

@Gaska said:

If yes, in what spec is it written?

POSIX. IEEE Std 1003.1-2001 (Single UNIX Specification).

@Gaska said:

How do I store an arbitrary object in string array? Well, first thing I'd do is get rid of string array.

When is an object not an object? When it is a serialization of an object.

LB_

@MathNerdCNU said:

If you want to make sure a file doesn't rename outside the scope of the editor, write one that takes a LOCK on the fucking file.

The point is that the file should still be able to be moved or renamed even when it is locked, and the save operation should always go to the file and not the text path where the file was first located when it was first opened.

IMO directories/files/paths should not be plaintext strings. The fact that certain character are disallowed from file/directory names is a clear sign that it's all just a hack.

Gąska

@dkf said:

POSIX. IEEE Std 1003.1-2001 (Single UNIX Specification).

The first link doesn't mention argv anywhere, the second I have no access to.

@dkf said:

When is an object not an object? When it is a serialization of an object.

Normally serialization is done in order to deserialize it later. Any use of serialized value without deserializing is

. The problem is, stdin, stdout, stderr, arguments and environment variables are meant to be used without any deserialization.

dkf

You've convinced yourself that you're correct, so why don't you go off and make your vision a reality? See if anyone will want to buy into it, or if people will inexplicably continue to Do It Wrong™.

LB_

@dkf said:

You've convinced yourself that you're correct, so why don't you go off and make your vision a reality? See if anyone will want to buy into it, or if people will inexplicably continue to Do It Wrong™.

The problem is that even if people liked it better, it would be too hard to transition to it.

dkf

@LB_ said:

The problem is that even if people liked it better, it would be too hard to transition to it.

antiquarian

@blakeyrat said:

Yeah I don't speak your gibberish moon-language, as you well know.

I understood it perfectly. You must have bash confused with Lojban.

sloosecannon

@blakeyrat said:

Look, you don't like the Mac Classic behavior because it's correct. You've probably never even thought about it longer than 46 nanoseconds.

You like it because it's what you're used to. Well. You got used to shitty broken behavior. Sorry.

FTFY

blakeyrat

Ok;

Explain to me how changing the name of a file changes which file is open in, say, Notepad. How is that correct?

Gąska

@dkf said:

You've convinced yourself that you're correct, so why don't you go off and make your vision a reality? See if anyone will want to buy into it, or if people will inexplicably continue to Do It Wrong™.

The problem is, I was born about 20 years after all this stuff was decided (which means about 60 years too late to have anything to say in that regard, not to mention I was born on the wrong side of the pond and on the wrong side of the iron curtain), and the giant supercorporations that rule in the IT world care about ass-backwards compatibility too much to change anything, even if they'd have agreed with me.

Still waiting for citation for that all environment variables are stored in argv.

dkf

@Gaska said:

Still waiting for citation for that all environment variables are stored in argv.

I'm not quite sure where you got that from. 'Cos they ain't. They're typically stored in the same space (there's a common overall limit on size, except on Windows which typically has a rather lower set of limits for this sort of thing in the first place) but that's not part of the interface specification, but rather of the implementations.

Gąska

@dkf said:

I'm not quite sure where you got that from.

@ben_lubar said:

Environment variables are passed to programs after their arguments. You can verify this with this program:

#include &lt;stdio.h&gt;

int main(int argc, const char *argv[]) {
        int i;

        for (i = argc + 1; argv[i]; ++i) {
                printf("%s\n", argv[i]);
        }
}
```</blockquote>

And since it looks like a terrible hack to me, I asked:

@Gaska <a href="/t/via-quote/51620/74">said</a>:<blockquote>Is it guaranteed by anything? If yes, in what spec is it written?</blockquote>

To which you replied:

@dkf <a href="/t/via-quote/51620/75">said</a>:<blockquote>[POSIX](http://a/%300). [IEEE Std 1003.1-2001 (Single UNIX Specification)](http://a/%300).</blockquote>

And now you say:

@dkf <a href="/t/via-quote/51620/85">said</a>:<blockquote>'Cos they ain't.</blockquote>

Which either means you lied that it's in the book, or you're lying right now.

@dkf <a href="/t/via-quote/51620/85">said</a>:<blockquote>that's not part of the interface specification</blockquote>
This further suggests that your earlier post was blatant lie.

@dkf <a href="/t/via-quote/51620/85">said</a>:<blockquote>but rather of the implementations</blockquote>
Are you supposed to actually rely on that on any system? If yes, in what spec is it written?

LB_

I thought enviroment vars were passed in as a third argument to main on some systems?

sloosecannon

Because changing the file name doesn't change which file is open. Notepad has opened "foo.txt". When you rename "foo.txt" to "bar.txt", Notepad doesn't magically open "bar.txt".

LB_

@sloosecannon said:

Because changing the file name doesn't change which file is open. Notepad has opened "foo.txt". When you rename "foo.txt" to "bar.txt", Notepad doesn't magically open "bar.txt".

You seem to be operating under the assumption that renaming a file is the same as deleting the file and then creating a new unrelated file with the same content. In this case Notepad should still have "bar.txt" open because it is the same file.

Gąska

@LB_ said:

I thought enviroment vars were passed in as a third argument to main on some systems?

It's not included in C or C++ standard, but is included in POSIX standard to which Windows might or might not conform.

@LB_ said:

You seem to be operating under the assumption that renaming a file is the same as deleting the file and then creating a new unrelated file with the same content.

Which, sadly, is exactly what most OSes do.

ben_lubar

@Gaska said:

Which, sadly, is exactly what most OSes do.

Really? Because Linux doesn't do that, and neither does Windows or Mac OS X or Plan9 for that matter.

accalia

@LB_ said:

You seem to be operating under the assumption that renaming a file is the same as deleting the file and then creating a new unrelated file with the same content. In this case Notepad should still have "bar.txt" open because it is the same file.

you* seem to be under the impression that Notepad keeps foo.txt open. it doesn't. all it does is bring read the contents of foo.txt into memory, close foo.txt, then remember where foo.txt is. that's why it created foo.txt on save when you renamed foo.txt to bar.txt

I know this is the case because if foo.txt was still open WINDOWS WOULD NOT ALLOW YOU TO RENAME IT

in this case it is not windows that is behaving wrong, it is Notepad.exe. if you dislike that behavior then get a better text editor.

*if not you then someone in this argument certainly is under that impression.

LB_

As I've stated a couple times before, the issue is that most operating systems and even libraries that abstract OS APIs don't provide any good or useful mechanism for uniquely identifying a file by something other than a string path. Sure, you can get notified of moves and renames, but that's not the same as just storing a UUID that always refers to the file.

@accalia said:

you* seem to be under the impression that Notepad keeps foo.txt open. it doesn't.

I thought we were talking about Theoretical Notepad^TM? You know, the one that runs on Theoretical Operating System^TM?

antiquarian

@accalia said:

in this case it is not windows that is behaving wrong, it is Notepad.exe. if you dislike that behavior then get a better text editor.

Wait, someone still uses Notepad?

accalia

@antiquarian said:

@accalia said:
in this case it is not windows that is behaving wrong, it is Notepad.exe. if you dislike that behavior then get a better text editor.

Wait, someone still uses Notepad?

that is the program that someone used very early on in this discussion to demonstrate why windows behaves wrong.

what they in fact demonstrated is that notepad.exe is a shit editor.

antiquarian

@accalia said:

what they in fact demonstrated is that notepad.exe is a shit editor.

- Taste the thatsthejoke

LB_

Notepad++ detects when the file is changed or deleted outside of its control, but it doesn't detect when the file is renamed. Not because Notepad++ is bad, but because it's not an easy thing to do in any OS to my knowledge. If someone knows how to detect renames/moves on Windows and/or on *nix, link me to the API documentation. (and no, deleting a file and then creating another file with the exact same content should not count)

Yamikuronue

This happens a lot to me: I have code open in sublime, I realize I want to put it in a subfolder, so I drop to explorer and move it. The file doesn't stop being what it is because it moved, but now if I save it in Sublime, I've made a copy at the old location instead of updating the original. The semantic meaning of "save my changes" has changed out from under me.

In my mind, I don't have C:\Users\Yamikuronue\Documents\Github\Sockbot\whatever.js open, I have "whatever.js for Sockbot" open. If that moves to C:\Users\Yamikuronue\Documents\Github\Sockbot\src\whatever.js, it's still "whatever.js for Sockbot" to me.

blakeyrat

@MathNerdCNU said:

The file name + path is the human readable identifier.

Right; it's meta-data.

What's the confusion here?

@MathNerdCNU said:

Intrinsic to the FILE. Not data ABOUT the file.

Oh; so in your warped mind, if I take a PNG of a sunset and renamed it "angry kitten.png", is it now an image of an angry kitten?

@sloosecannon said:

Just because you're used to your buggy Mac Classic OS doesn't mean you should force the rest of the world to operate that way too.

I can cope with the way Windows works, but there's no way this behavior is not a bug.

@ben_lubar said:

If they kept the file open, @blakeyrat wouldn't be able to rename the file because Windows automatically locks files that are in any kind of thing resembling use.

Right; which is just replacing one bug with another.

@sloosecannon said:

True... which exemplifies how ridiculous that idea is......

It's SO ridiculous it was the default and correct behavior in an OS that sold millions and millions of copies. HOW RIDICULOUS!

blakeyrat

@sloosecannon said:

Because changing the file name doesn't change which file is open. Notepad has opened "foo.txt". When you rename "foo.txt" to "bar.txt", Notepad doesn't magically open "bar.txt".

Right; but you're saying instead that renaming the file creates a SECOND file. Which is the behavior I'm observing-- you renamed foo.txt, now you have two files: one named bar.txt in Explorer and one named foo.txt that exists in Notepad but not yet on disk.

How is that desirable behavior? Is this what you think the naive user would expect to happen when a file is renamed?