Scripting Bugs

[jacky]

It's jacky's fault! He told me!

Wait, what? When? Not possible I wasn't even there!

BTW it might be my old DOS days speaking, but the main and huge difference for disk is this :
C:\ means the root of drive C
C: means drive C: - as in no folder specified

Back in DOS, it meant whatever the current folder on that drive is. I'm not exactly sure how it is handled by Windows, but the distinction between a drive and a path (C: is a drive, C:\ is a path) still applies.

Here, open a command prompt and do this: (assuming you got a folder WINDOWS on your drive C: of course )

Code: Select all

C:
CD \WINDOWS
D:
DIR C:
DIR C:\

You'll see you won't get the same results. And doing a "copy somefile c:" or "copy somefile c:" would work the same.

That's why on XY looking at the Tree you do see "C:" without a backslash, it's a drive. Just like you read "WINDOWS" and not the full path for folders. But when you go there, on the window's title, AB, Tab, etc you'll read the current path, eg. C:\

/me shuts up now

[PeterH]

Oh dear...

First my thinking: windows is inconsistent! For example in addressbar in Win Explorer or in XY you always see an absolute path, don't you? While in the DOS-examples of Jacky there is absolute (dir c:\) or relative (dir c: ) path for a command.
But you can "copy somefile c:system32" or "copy somefile c:\system32" and it would be very different (Jacky: hope you meant to say that the copies are *not* the same, what is same as in displays? ) Did you ever see something like c:system32 in addressbar of WinExplorer or XY?

So if you say, c:\windows does not end on \, I think c: should not, as well! As, when I expect any path, after appending \file.txt to it, becomes a qualified name, then I expect the same for the path of c:

And I think, Windows says I'm right, as when you enter "set" in command-window (you may call it DOS?) you see the variable homedrive is filled wit c:, that is, it ends without \ as any other path in a variable!

This means: I don't understand, why WinExplorer shows c:\ - I think this is not correct! But it seems to be no problem - as nobody uses it in a script there

OK - and when doing scripting, you need to be reliable! (As much as possible!) And so I would end any path without \ - even if it's a drive!

[jacky]

Jacky: hope you meant to say that the copies are *not* the same, what is same as in displays?

Yeah, bit unclear there. I meant to say those two commands are not the same, they behave the same as did the DIRs in the example before : on copies to the current path on drive c, the other to the given path (root)

So if you say, c:\windows does not end on \, I think c: should not, as well!

Yeah, but that's the trick : it needs to be a path, and c: is not! It is a drive only. that's why there's always the "problem" that adding a "" to a path must ensure that the path isn't to a drive's root (where it's already there) !

And I think, Windows says I'm right, as when you enter "set" in command-window (you may call it DOS?) you see the variable homedrive is filled wit c:, that is, it ends without \ as any other path in a variable!

That's where you're wrong : homedrive is NOT a path, but as it names implies it is a drive. Should it be a path, like homepath, it would then be c:\ of course.

This means: I don't understand, why WinExplorer shows c:\ - I think this is not correct!

Yes it is, because it refers to the path, not the drive. C: is the drive, the entire drive, it is not a location if you will. Whereas C:\ is a path, a location : the root of drive C:

Basically : a path must point to either a file or a folder. C: does not, C:\ does.


But in the end we agree that if the current path is a root, it should return the drive only, no backslash. It's technicaly not the current path, but it'll be as good and will avoid any question or test : always add a backslash after that variable, no matter what.

[j_c_hallgren]

Maybe XY could get smart and check for a case of "D:\" and "fix" it on the fly for us ? Or would that somehow be a bad idea ?

I've been watching the 'what is a path' discussion here with some amusement but think that jacky had a good idea here in that XY could just look for double \\ and remove the extra one...

[PeterH]

Hey, j_c is laughing! I understand that - and I think I'll give him a bit more to laugh.
Not at jacky or so, but just about the situation
Are we just talking about words and names of things?

OK - think about the leading part of the complete name of a file, which is some level of directory. And if expanded by, for example, \system32, is a deeper level of directory. And expanded by \file.ext is an explicit file. You may call it path, or whatever. But the lowest level for this thing is c: - if it would be c:\, and I add \windows, it would be c:\\windows.
And if the definition of path is such that only in most times I would be able to append \windows to reach a sub-directory, or \boot.ini to reach a file, I would not like to work with it. Expecially not with scripts!

That's my view of the situation.

Maybe a solution: show c:\ in address bar, but fill path variable with c:

[jacky]

Back in this, for obvious reasons (and consistency) it would be nice to "adjust" what is returned by inputfolder since, as it's a Window command, it always returns a path (so D:\Folder but D:\ !)

[admin]

Back in this, for obvious reasons (and consistency) it would be nice to "adjust" what is returned by inputfolder since, as it's a Window command, it always returns a path (so D:\Folder but D:\ !)

Yes! Will do.....

[jacky]

hmm.. not sure if this is expected or not, I would think not.

Before (just don't ask me before what, I ain't sure exactly) when a script showed a rename preview, pressing Cancel would abort script execution - much like input, inputfile or inputfolder

But now, pressing Cancel doesn't abort the script anymore, just closes the window and moves on.

[admin]

hmm.. not sure if this is expected or not, I would think not.

Before (just don't ask me before what, I ain't sure exactly) when a script showed a rename preview, pressing Cancel would abort script execution - much like input, inputfile or inputfolder

But now, pressing Cancel doesn't abort the script anymore, just closes the window and moves on.

No, this was never implemented. But I'll add it.

[jacky]

No, this was never implemented. But I'll add it.

Oh yeah, you're right, it was never there. Turns out I can't read!

[TheQwerty]

It's all broke.

With 6.80.0075 XY's not recognizing most commands.


Nevermind... you just made it case sensitive.

[admin]

It's all broke.

With 6.80.0075 XY's not recognizing most commands.

For example?

[TheQwerty]

It's all broke.

With 6.80.0075 XY's not recognizing most commands.

For example?

Nothing.. as I said in the edit, you just made it case sensitive. (Boo!)

[jacky]

Well, despite the case issue, one thing is broken though : registered applications.

We used to be able to specify a registered application by quoting it, eg. by putting "winrar" or "notepad" (quotes included) no need to specify a path. Well, this doesn't work anymore, as ::open """notepad""" gets this:
Couldn't find application:
D:\Program Files\XYplorer\notepad

PS: Works fine for openwith but not with open, although it's required with open as well to send parameters to the app!

[admin]

It's all broke.

With 6.80.0075 XY's not recognizing most commands.

For example?

Nothing.. as I said in the edit, you just made it case sensitive. (Boo!)

Whoops, not on purpose! Fix is coming...