@ScriptDir returns trailing slash

[BinaryBrother]

@ScriptDir

Directory containing the running script. (Result doesn't contain a trailing backslash)

I'm not really sure what's happening here. Either I'm overlooking something, or the trailing slash behavior just changed on me, mid script.

I am running AutoIt Version 3.3.8.1.

Is this behavior expected, or is this a bug?
 

Windows 7 x86

Summery: @ScriptDir is giving me, C: when it should be giving me C:.

 

Edited July 30, 2013 by BinaryBrother

[wraithdu]

Yeah.. this is one of those things.. it's always been that way, but I personally consider it a bug, or at least inconsistent behavior. Maybe you should submit a Trac ticket.

[guinness]

It has been like that for as long as I have been using AutoIt.

[BinaryBrother]

Haha. I'm surprised it's taken me this long to notice that it was returning inconsistent results. What a weird thing to notice after all this time...

Trac Submitted:http://www.autoitscript.com/trac/autoit/ticket/2373#ticket

 

Edited July 30, 2013 by BinaryBrother

[wraithdu]

It only happens in root directories, and really, scripts shouldn't run from there, especially with UAC. It's one of those sneaky gotchas.

[JLogan3o13]

I believe it only does it at the root of C:. I have tried it when the script is saved elsewhere, and it doesn't return the trailing slash. Maybe that is why you haven't noticed it

 

Edit: Too slow

Edited July 30, 2013 by JLogan3o13

[BinaryBrother]

Yep, you guys are probably right. I never run scripts from root, but I'm working on a project that's working with the root directory of a Network Drive. At first, I thought it was a Network Path bug, but then I tested on my local drive before I posted, hence the C: in the screenshot.

 

 

[wraithdu]

Kind of a PITA, but you could wrap the macro. Also, this is the same behavior of other dynamic directory macros like @WorkingDir.

ConsoleWrite(@ScriptDir & " | " & _ScriptDir() & @CRLF)
ConsoleWrite(@WorkingDir & " | " & _WorkingDir() & @CRLF)
FileChangeDir("C:\")
ConsoleWrite(@WorkingDir & " | " & _WorkingDir() & @CRLF)

Func _ScriptDir()
    Return StringRegExpReplace(@ScriptDir, "\\+$", "")
EndFunc

Func _WorkingDir()
    Return StringRegExpReplace(@WorkingDir, "\\+$", "")
EndFunc

[MHz]

@ScriptDir used to return C: where C is the drive letter. But it would be an issue for some who did not check so the backslash is appended for when @ScriptDir is in the root. It was a fix to avoid problems that may occur.

19th December, 2006 - v3.2.2.0

Fixed: @ScriptDir equal @WorkingDir for rootdir (x:).

[BrewManNH]

BTW, this is completely valid as far as Windows is concerned, "C:Temp"

[guinness]

So is this...

ConsoleWrite(FileExists("C:\\\Users\\\\\\guinness\\\Desktop\\\\\\\\\\\\\\\\\\\\\\\\\\Exampel.txt") & @CRLF) ; Returns 1.
ConsoleWrite(FileExists("C:\\\Users\\\\\\guinness\\\Desktop\\\\\\\\\\\\\\\\\\\\\\\\\\ExampleNotExists.txt") & @CRLF) ; Returns 0.

[BinaryBrother]

I was just about to ask that, BrewManNH.
Being as Windows will accept these paths, gracefully, I guess I'll just leave it. ^.^
 

[Richard Robertson]

It's worth noting that "C:" and "C:" are very different paths. "C:" returns the current working directory in the C drive where as "C:" is the root directory of the C drive.

This is why *nix paths are so much easier with no namespaces.

[jpm]

Hi,

As I did the mod long time ago,

@Scripdir mus be the same as @workingdir for the root.

Just think what happens if you use in a FileChangeDir(@Scriptdir) for a script being in the root

No change will occur if no "" for root

JP

[Jon]

FileChangeDir would actually work fine with C: according to the API for SetCurrentDirectory so I don't think that was why it changed.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365530(v=vs.85).aspx

 

The string must not exceed MAX_PATH characters, including the terminating null character. The final character before the null character must be a backslash (''). If you do not specify the backslash, it will be added for you;

 

That said vbscript has the exact same behaviour where it only adds on a backslash at the root, so I'm inclined to leave it alone.

Set objShell = CreateObject("Wscript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

strPath = Wscript.ScriptFullName
WScript.Echo strPath

Set objFile = objFSO.GetFile(strPath)
strFolder = objFSO.GetParentFolderName(objFile) 

WScript.Echo strFolder

[KaFu]

CreateFile
"When opening a volume or removable media drive (for example, a floppy disk drive or flash memory thumb drive), the lpFileName string should be the following form: ".X:". Do not use a trailing backslash (), which indicates the root directory of a drive."

[Ascend4nt]

KaFu, that path requirement is for opening drives as an I/O device, which is a different beast altogether.  Paths for them are very much governed by the device type.. 

I've actually >used that method before

[KaFu]

Yeah, I know. The important part is the second one: Do not use a trailing backslash (), which indicates the root directory of a drive.

So "x:" refers to drive itself (e.g. for accessing the MFT) and "x:" refers to the root directory of the drive.

[Richard Robertson]

Yeah, I know. The important part is the second one: Do not use a trailing backslash (), which indicates the root directory of a drive.

So "x:" refers to drive itself (e.g. for accessing the MFT) and "x:" refers to the root directory of the drive.

However, this is unrelated to the current discussion as you would never use the working directory or script directory with the assumption that it is a drive root.

[jpm]

However, this is unrelated to the current discussion as you would never use the working directory or script directory with the assumption that it is a drive root.

but some put script under the root !!!