Jump to content
Sign in to follow this  
cherdeg

@ScriptDir - inconsistent behaviour

Recommended Posts

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 by cherdeg

Share this post


Link to post
Share on other sites
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.

:mellow:


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

:mellow:

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.

:(


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
cherdeg

Just...go and get stuffed :mellow:

Share this post


Link to post
Share on other sites
PsaltyDS

Just...go and get stuffed :mellow:

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

:(


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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 by spudw2k

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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? :mellow:

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
cherdeg

@Brett:

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
cherdeg

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

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

Share this post


Link to post
Share on other sites
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.


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×