SciTE bugs

[bengalih]

Where is the proper place to file a bug for the version of SciTE included with AutoIt?

I tried to download the latest version of SciTE from the Scintilla page, but the version there doesn't seem to be able to actually run AutoIt scripts (F5), so I can't actually test if the bug exists there.

The bug has to do with how parameters (shift+f8) are handled within SciTE compared to how they are actually handled on the command line.

Do I file the bug at:

https://sourceforge.net/p/scintilla/bugs/new/

Or somewhere AutoIT specific?

Thanks.

[bengalih]

I'll go ahead and post the full issue here in the hope that maybe someone else has an idea.

Here is the following script:

#include <Constants.au3>
ConsoleWrite("START" & $CmdLineRaw & "END")

If this code is executed from the command prompt (compiled CUI) as follows:

test.exe username=jsmith password=password123

Then the resulting output shows:

STARTusername=jsmith password=password123END

This is as expected.

However, if the same code is run from SciTE (F5), by setting the first 2 parameters with Shift+F8, the resultant output is:

START/ErrorStdOut "C:\Users\bhendin\Desktop\test.au3" username=jsmith password=password123  END

Note the extra space added to the end of the raw command line before "END".

This does not happen if you set "password=password123" as the LAST parameter in SciTE (the 4th one).

This would seem to definitely be a bug.

Edited June 9, 2016 by bengalih

[Jos]

This is working as designed and is no ScITE bug as such.
Spaces are required between parameter, so the only proper option for the commandline as defined in au3.properties is:

command.go.$(au3)="$(SciteDefaultHome)\..\AutoIt3.exe" "$(SciteDefaultHome)\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "$(FilePath)" /UserParams $(1) $(2) $(3) $(4)
command.go.subsystem.$(au3)=1

As you can see, there are spaces between the variables $(1) - $(4), which means that these spaces will always be there. This "normally" shouldn't cause any errors on a commandline.

Jos 

[bengalih]

Thanks for the reply Jos and pointing me to where the problem is introduced, I was not previously familiar with how this worked via the au3.properties.

However I have to disagree here: whether you want to call it a bug or "by design" is semantics, but the fact is the behavior differs whether run from the command line or run from within SciTE.

I 100% agree that there needs to be a space between each command-line parameter, however the problem is that SciTE assumes that 4 command line parameters will be given even when they are not.

The product should behave consistently and give consistent output.  Even if you want to argue that SciTE is a product apart from AutoIt, even *within* ScitTE the behavior differs.

If I set "$(3)=mytext" then the resultant raw will be "mytext " (extra space).  If I set that same value to $(4) then the resultant output is "mytext" as desired.

The fact is that code which works perfectly when run from a script (compiled or .au3) will have different output when given the same command line parameters.

If I delete the last parameter from the au3.properties then things work, but this isn't practical.  It would seem that SciTE should be able to know how many parameters you have actually supplied and only pass the supplied ones to the command line (as the actual autoit compiler would do).

In the meantime, can you think of a workaround for this?

I can't just strip the last space from the line because it may be a valid character in the passed parameter (if the parameter was last).

I would like to be able to test if the script is being run from within SciTE, then if it is, I want to see if the "password=" argument is placed anywhere prior to $4 and followed by one of more empty argument.  I don't seem to be able to test for a parameter argument at all (e.g. isDeclared) if it is not even passed.

Thanks

[Jos]

23 minutes ago, bengalih said:

In the meantime, can you think of a workaround for this?

There are many workarounds one could think of and the most simple would be that your script strips any trailing spaces or does "proper" commandline lexing, as spaces are considered delimiters on a commandline

Jos

[bengalih]

Neither of your solutions are workable for the use case in question.

A password is being provided as a parameter.

A password can have spaces and quotes in it (these are viable characters in many directory service/auth implementations).

[my" pa$$" w0rd! ]   == a perfectly valid password (note the  [ ] are used as delimeters, so that the trailing space after the ! is a valid character in the password).

Situations like this are, it appears, the very reason why CmdLineRaw exists, so that one can apply their own parsing rules.

And, as I have pointed out the code works 100% perfectly outside of SciTE because AutoIt does not assume that an undeclared parameter should be preceded by a space.  It is only the SciTE settings for AutoIt (au3.properties) that you mention is coded in a way as to change that functionality.

If you can provide a solution to the use case that doesn't involve CmdLineRaw and bypasses this issue, I would like to consider it.

Otherwise, I will continue to contest that if this is "by design" then it is bad design *if* a goal of SciTE is to provide the same output that running a script outside of it would provide.  Since this use case shows that it does not do that.

We can of course disagree here, which leads me back to my original question of "Where is the proper place to file a bug for the version of SciTE included with AutoIt?"

I can post this there and all the developers can determine if this is actually the desired behavior (as opposed to currently designed behavior).

I can see from the comments inside au3.properties that you appear to have worked on this yourself.  If indeed you are where the buck stops then I would hope we can reach some happy medium.  It appears based on the current design it would be almost impossible to remedy this situation based on how SciTE reads the properties file and there appears no way to dynamically change the content of that line based on how many parameters are actually defined.

That being said....if there was a way in my script to:

• Determine it is being run by SciTE as opposed to outside of it.
• Determine how many parameters are actually being passed (don't have "" value)

If I could do both of those things I believe could script around.

Without a solution you are telling me that my use case can't be handled appropriately, which means that AutoIt is not the tool for the job (or at lease SciTE is not).  That may be true, but it seems that the flexibility of this tool and the knowledge of this community has rarely found a problem it couldn't solve. 

Thanks again for your comments.

Edited June 9, 2016 by bengalih

[Jos]

Geeeezzz ... you probably should take up writing novels!    

And please stop all this arguing about right or wrong. A space is a delimiter for command lines ... right or wrong? 

Now back to seeing if we can find a easy solution for your problem: Have you tried using parameter 3 & 4  in stead of 1&2 and is that working?

Jos

[bengalih]

I'm not arguing right or wrong (this isn't a moral discussion), this is about good program design.  I won't pretend that my development skills are at your level, but I find it strange (as a professional/semi-professional developer) that you would argue that if SciTE's output is different than what non-SciTE output is being fed the same parameters then there isn't something fundamentally wrong with that.  Forget about this particular issue, or the scope - it is inconsistent and thus poor design.  Please take that statement with all due respect as I respect the work of everyone that has developed AutoIt.

Every piece of software has limitations and none is perfect.  IMHO the way parameters were implemented in SciTE didn't fully take into account all the ways which parameters can be used within AutoIt.  The fact that only 4 are available is an obvious limitation we don't need to dispute.

As far as space being a delimiter for a command line.  No, I wouldn't necessarily state that was accurate as a general, after all you can enclose spaces within quotes and so that is technically inaccurate.

You are correct that if 3 & 4 is used the problem isn't exhibited but to remember that on each run (and to impart that onto others who may reuse) is a tricky proposition and I would like to have a more elegant solution (as in minimize user interaction to prevent possible issues).

thanks

[Jos]

3 minutes ago, bengalih said:

it is inconsistent and thus poor design

I am open for any good suggestions that would improve and have no issue when people don't like the stuff I publish as you are free to use it OR NOT.

5 minutes ago, bengalih said:

No, I wouldn't necessarily state that was accurate as a general, after all you can enclose spaces within quotes and so that is technically inaccurate.

So the answer is Yes unless Quoted, so that means your current script doesn't handle it properly. You can always request suggestions for your commandline lexing when you post the code you use to interpret the total string. 

5 minutes ago, bengalih said:

You are correct that if 3 & 4 is used the problem isn't exhibited but to remember that on each run (and to impart that onto others who may reuse) is a tricky proposition and I would like to have a more elegant solution (as in minimize user interaction to prevent possible issues).

Ok... my final comments for you:

• You have a solution for your issue!
• SciTE is a development environment giving you the options to develop and test scripts.. again, no hard feelings when you don;t use it and use your own preferred Editor, but would appreciate you stop lecturing me as I am not open to that. 
• Define your own commandline with only 2 parameters in your SciTEUSer.properties with its own shortcut when you are still emotional about it and want another alternative.

I am done with this thread and wish you a good day and happy scripting.
Jos

ps: Your welcome!

 

 

 

[bengalih]

Great!  Thanks for being done with this thread so I can have the last word.

As a product developer, one can only assume you want someone to use your product.

Why then, take these holier-than-though omnipotent attitudes when an issue is brought to your attention?

Everyone makes mistakes.  No one designs software 100% perfectly.  There are ALWAYS new use cases that you couldn't imagine and thus account for when first designed.

Someone bringing these issues up doesn't mean they think you are an idiot.  It doesn't mean they think your software is garbage.  Otherwise, why would they care?  They wouldn't take the effort.  I like this software, I want to continue using it and by my (and other's) use they provide feedback about how things can improve.

I've been incredibly diplomatic this entire thread and you have been overly defensive bordering on rude and hostile.
"This is by-design...and by god it is right!"
"Your use case is stupid. (or worse assume you understand all factors involved in a use case)."
"I'm unwilling to accept that there is something in the universe I didn't foresee."
"I will only answer your questions with indirect answers that avoid admitting any issue with myself or anything I've ever done."

These are the kind of attitude that destroys products and communities.

Clearly SciTE has limitations as you accept when you state you "open for any good suggestions that would improve".  Honestly, I don't know the best way to handle it based upon why I see this is happening.  The only way I see to prevent it (apart from hokey workarounds like changing parameter placement, etc), would be for SciTE to know how many parameters it was passed and not just include a space for undeclared parameters.  I don't know how to implement that, but AutoIt clearly does because it works properly there.

SciTE doesn't handle it the same way because whomever wrote that piece of code didn't believe it would be an issue, but clearly it can be in certain scenarios.  Again, this DOESN'T mean that person is stupid or messed up - it just means they are human.

At the very least I hope this thread brings attention to this issue for anyone else that may be experiencing it and they don't need to go through the tooth pulling exercise (both in figuring out what was wrong and in dealing with obstinate developers).

Happy coding.

p.s.  Thanks

Edited June 9, 2016 by bengalih

[JLogan3o13]

@bengalih you have gone from expressing an opinion to beating a dead horse, to now just being annoying. I would suggest you drop it. If this isn't the tool for you, move along.