@ScriptDir - inconsistent behaviour

[cherdeg]

Hi,

I use @ScriptDir in several of my scripts. And each time I have to work around it's inconsistent behaviour:

Global $s_ScriptHome = @ScriptDir
$s_ToolsShare = $s_ScriptHome & "\Tools"
MsgBox("", "TEST", $s_ToolsShare)

Started from a drive root, this returns e.g. "d:\\Tools". Started from a UNC-path or local subdirectory, it returns "\\servername\sharename\foldername\Tools" or "c:\folder\Tools" (please mind the number of backslashes). If @ScriptHome's behaviour was consistent, it would either always or never return the closing "\". But doing it on

@Developer-Team: Please fix in next release!

Thank you very much,

Regards,

Chris

Edited November 6, 2008 by cherdeg

[PsaltyDS]

Hi,

I use @ScriptDir in several of my scripts. And each time I have to work around it's inconsistent behaviour:

Global $s_ScriptHome = @ScriptDir
$s_ToolsShare = $s_ScriptHome & "\Tools"
MsgBox("", "TEST", $s_ToolsShare)

Started from a drive root, this returns e.g. "d:\\Tools". Started from a UNC-path or local subdirectory, it returns "\\servername\sharename\foldername\Tools" or "c:\folder\Tools" (please mind the number of backslashes). If @ScriptHome's behaviour was consistent, it would either always or never return the closing "\". But doing it on

@Developer-Team: Please fix in next release!

Thank you very much,

Regards,

Chris

Search the forum before you post, especially proposing bug reports. This has been discussed MANY times already.

The behavior is consistent with other languages and is based on the logic that "D:" is not a directory, therefore "D:\" is more appropriate for @ScriptDir. It is even consistent with other operating systems that sensibly don't even use drive letters, like various Linux-based distros where pwd will return "/home/PsaltyDS" in home directory, but returns "/" for root.

No bug.

[Bert]

agreed. NO BUG

[cherdeg]

Search the forum before you post, especially proposing bug reports. This has been discussed MANY times already.

Yes, I know. Because I searched. But sadly the search delivered NO SINGLE satisfying result.

The behavior is consistent with other languages and is based on the logic that "D:" is not a directory, therefore "D:\" is more appropriate for @ScriptDir. It is even consistent with other operating systems that sensibly don't even use drive letters, like various Linux-based distros where pwd will return "/home/PsaltyDS" in home directory, but returns "/" for root.

No bug.

Hey: I'm not using C, C++ or C#. Neither I'm using Java, Python or PHP, nor Pascal, Delphy or VB. I am using AutoIT! If something is appropriate or not should depend on its practical relevance and not on overcome principles. And last but not least I again use ... AutoIt, which implicates that I am using Windows as operating system and nothing else. So why care for facts on 'xes? If it's not a bug, it's by all means nothing less than a major annoyance. And sorry, but If something returns at one place a "\" and at another place not, is this a matter of inconsistency - and only by repeatedly telling users the opposite, your assertion won't get truer.

But, if you don't want to ease the allover usage of AutoIt by changing @ScriptDir, why not create simply a macro @ScriptLoc or @ScriptHome? Doing that you guys could keep up your strange, inexplicable and crude logic and still make life easier for the people using AutoIt.

Regards, Chris

[PsaltyDS]

Yes, I know. Because I searched. But sadly the search delivered NO SINGLE satisfying result.

Hey: I'm not using C, C++ or C#. Neither I'm using Java, Python or PHP, nor Pascal, Delphy or VB. I am using AutoIT! If something is appropriate or not should depend on its practical relevance and not on overcome principles. And last but not least I again use ... AutoIt, which implicates that I am using Windows as operating system and nothing else. So why care for facts on 'xes? If it's not a bug, it's by all means nothing less than a major annoyance. And sorry, but If something returns at one place a "\" and at another place not, is this a matter of inconsistency - and only by repeatedly telling users the opposite, your assertion won't get truer.

But, if you don't want to ease the allover usage of AutoIt by changing @ScriptDir, why not create simply a macro @ScriptLoc or @ScriptHome? Doing that you guys could keep up your strange, inexplicable and crude logic and still make life easier for the people using AutoIt.

Regards, Chris

You're right! You should demand that Jon refund your AutoIt purchase price! And Microsoft should change the behavior of "CD" at the DOS prompt and the matching macros in all their languages, too!

All seriousness aside, you could just write a _ScriptDir() function for yourself that sets up the string as you like it and always put _ScriptDir() in place of @ScriptDir.

[senthor]

Func _ScriptDir()
    If StringRight(@ScriptDir, 1) = "\" Then
        return SetError(0,0,StringTrimRight(@ScriptDir, 1))
    Else
        return SetError(0,0,@ScriptDir)
    EndIf
EndFunc

Happy now?

[cherdeg]

Just...go and get stuffed

[PsaltyDS]

Just...go and get stuffed

No thanks, I just had lunch...

The code from senthor actually corrected a misunderstanding for me. I didn't think it would work because SetError() wouldn't return anything but an integer. I had forgotten that was fixed a long time ago and you could return anything with it now:

; Set @error test
For $n = 1 To 4
    $RET = _Test($n)
    $iErrSav = @error
    $iExtSav = @extended
    $sType = VarGetType($RET)
    ConsoleWrite("$RET = " & $RET & "  Type = " & $sType & "  @error = " & $iErrSav & "  @extended = " & $iExtSav & @LF)
Next

Func _Test($i)
    Switch $i
        Case 1
        ; integer
            Return SetError(1, 1, 1)
            
        Case 2
        ; float
            Return SetError(2, 2, Sqrt(2))
            
        Case 3
        ; string
            Return SetError(3, 3, "Three")
            
        Case 4 
        ; array
            Return SetError(4, 4, StringSplit("1,2,3,4", ","))
    EndSwitch
EndFunc

[senthor]

Even Most Venerable Penguins can learn something more

Edited November 6, 2008 by senthor

[spudw2k]

Just because someone offered a reasonable and simple method to correct your issue, it doesn't mean you should take offense. C:\\tools should work anyways as pointed out by Hubertus.

Edited November 6, 2008 by spudw2k

[cherdeg]

Hey guys, very nice of you to inform me that "C:\\Tools" is working...sometimes. Not that I wouldn't know myself...but I suppose none of you has to care about systems running Windows NT or Windows 2000, right? But alas I (have to) do.

Just test this on W2K, you hardly won't find any NT systems still floatin' 'round anywhere...

Global $s_ToolsShare = @ScriptDir & "\Tools"
$i_RVal = FileExists($s_ToolsShare & "\" & $s_RegFile)
If $i_RVal <> 1 Then
    MsgBox(16, "TEST", "Error! The registry-file " & $s_RegFile & " was not found!", "")
    Exit
EndIf

The code simply won't do the magic on any OS before XP and with a value like "D:\\Tools" for $s_ToolsShare; $i_RVal will never be "1" in such a situation. This was the reason that originally brought me here...

Regards,

Chris

[spudw2k]

The code simply won't do the magic on any OS before XP and with a value like "D:\\Tools" for $s_ToolsShare; $i_RVal will never be "1" in such a situation. This was the reason that originally brought me here...

Regards,

Chris

Does Senthor's solution not work for you?

Func _ScriptDir()
    If StringRight(@ScriptDir, 1) = "\" Then
        return SetError(0,0,StringTrimRight(@ScriptDir, 1))
    Else
        return SetError(0,0,@ScriptDir)
    EndIf
EndFunc

Happy now?

[cherdeg]

Does Senthor's solution not work for you?

I'm sure it would - but I'm not in search for a solution: In my tools I use a stringreplace(). All I want is to tell you guys, that @ScriptDir is not perfect and that, no matter which further criterions you enumerate, this fact won't change.

[BrettF]

It's perfect, you obviously don't think it is, but it is- in other words it does what is intended. It will not be changed and you have a solution, so why are you still here complaining?

If you'd taken 30seconds to search for this, you would have found that it has been discussed before, and deemed as a NOBUG.

Cheers,

Brett

[cherdeg]

@Brett:

...no matter which further criterions you enumerate, this fact won't change.

[spudw2k]

I'm sure it would - but I'm not in search for a solution: In my tools I use a stringreplace(). All I want is to tell you guys, that @ScriptDir is not perfect and that, no matter which further criterions you enumerate, this fact won't change.

Well you know, you could always find another language to play with if this one doesn't work for you; one that offers "perfect" (by your definition) pre-made macros and methods.

[cherdeg]

But using root directory as script repositoty is also not perfect.

- Righty-Rrrright. But if you have to run a tool by autorun.inf from a CD...

[SmOke_N]

@cherdeg ... It is good that you have found that you need a solution (My personal preference is RegExp one), rather than having systems bouncing your script with unwanted errors (or maybe that's how you found the errors to begin with?).

Rather than arguing with everyone, I'd suggest you open a ticket (as a feature request) to the Devs on your concern and or wishful solution. The worse case scenario there is you get told yourself to get stuffed. Either way, you have your own solution to the issue, and can avoid a lack of understanding.