Go, Go, Gadget Depends!
-
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.
-
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?
-
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.
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.
-
Was Mac Classic any way *nix related? From what I recall Classic Mac was whatever Jobs and crew
were inspired bystole after visiting Xerox PARC.
-
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.
-
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.
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.
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.
-
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.
-
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.
-
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.
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.
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.
-
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?"
Dependency hell ahoy!
Indeed. Some googling revealed having more than one thing in GOPATH is a BAD idea.
-
Environment variables are passed to programs after their arguments. You can verify this with this program:
WTF? I didn't know that. Interesting.
-
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.
-
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.
-
True... which exemplifies how ridiculous that idea is......
-
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.
-
it's correct
As opposed to the Linux behavior, which would do what your Mac OS 9 example had that was "correct" before?
-
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.
-
$ touch blakeyrat.txt $ (sleep 5 && echo "butts") >> blakeyrat.txt & mv blakeyrat.txt fred.txt $ cat fred.txt butts
-
Yeah I don't speak your gibberish moon-language, as you well know.
-
This post is deleted!
-
This post is deleted!
-
-
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.
-
Environment variables are passed to programs after their arguments.
Is it guaranteed by anything? If yes, in what spec is it written?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.
-
If yes, in what spec is it written?
POSIX. IEEE Std 1003.1-2001 (Single UNIX Specification).
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.
-
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.
-
POSIX. IEEE Std 1003.1-2001 (Single UNIX Specification).
The first link doesn't mentionargv
anywhere, the second I have no access to.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.
-
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™.
-
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.
-
The problem is that even if people liked it better, it would be too hard to transition to it.
-
Yeah I don't speak your gibberish moon-language, as you well know.
I understood it perfectly. You must have bash confused with Lojban.
-
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
-
Ok;
Explain to me how changing the name of a file changes which file is open in, say, Notepad. How is that correct?
-
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
.
-
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.
-
I'm not quite sure where you got that from.
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]); } } ```</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?
-
I thought enviroment vars were passed in as a third argument to
main
on some systems?
-
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".
-
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.
-
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.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.
-
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.
-
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.
-
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.
you* seem to be under the impression that Notepad keeps foo.txt open. it doesn't.
I thought we were talking about Theoretical NotepadTM? You know, the one that runs on Theoretical Operating SystemTM?
-
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 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.
-
what they in fact demonstrated is that notepad.exe is a shit editor.
-
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)
-
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.
-
The file name + path is the human readable identifier.
Right; it's meta-data.
What's the confusion here?
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?
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.
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.
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!
-
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?