Python Scripting
Moderators: Hacker, petermad, Stefan2, white
Python Scripting
Python lovers, can we please have a Python scripting plugin(s) to execute Python scripts? I don't think it should be that hard to implement considering the fact that the Python script engine is included in so many software products. There are script WFX plugins such as VBScript, JScript but they're not as feature-rich as Python.
Last edited by billiebub on 2012-09-06, 23:24 UTC, edited 2 times in total.
I guess it's a Delphi world then. Everything is Delphi. The interpreted programming options are so limited and this also limits the quantity and quality of functionality.
Can you think of the kind of plugins that can be written using Python by leveraging it's powerful API? Anyone then could come up with plugins. Delphi vs Python...let's not go there. Python is so much easier to learn, extend and it's widely used. There are tons of libraries that are written in Python. Interpreted vs compiled.
Mr. Sigler, haven't you ever thought of including a scripting language to extend the functionality of TC besides compiled plugins?
Please consider such a powerful add-on to TC.
Can you think of the kind of plugins that can be written using Python by leveraging it's powerful API? Anyone then could come up with plugins. Delphi vs Python...let's not go there. Python is so much easier to learn, extend and it's widely used. There are tons of libraries that are written in Python. Interpreted vs compiled.
Mr. Sigler, haven't you ever thought of including a scripting language to extend the functionality of TC besides compiled plugins?
Please consider such a powerful add-on to TC.
-
ThomasMuders
- Junior Member
- Posts: 5
- Joined: 2008-08-11, 14:14 UTC
Actually, there is a Pascal Script engine for Delphi, which is not bad.
http://www.remobjects.com/ps.aspx
I have used it, because it's included in InnoSetup.
http://www.remobjects.com/ps.aspx
I have used it, because it's included in InnoSetup.
I've researched the Pascal Scripting Engine from remobjects and some people have decided to fork their own because this is what they say about it:
TC Plugin author who wrote the scriptWFX which executes VBScript was a success because he relied on the VBScript scripting engine, a mature engine that's been used since the beginning of Windows. The only issue I see with scriptWFX is the limitation of VBScript's in terms of:
1. limited out of the box collection of modules
2. not platform independent. Think of modules that were written to work under Linux/Solaris/Unix. They can also work under Windows (most of them) if Python were to be used.
Python already provides the scripting engine to be used as part of applications to extend their functionality. The question is, why bother reinventing the wheel when it already exists?
Forget about trying to fork a scritping language out of a compiled one and stick to using a mature, well-known one. Very simple.
To be honest I was not surprised to read the above comment. After all, Pascal is not a scripting language. Just imagine trying to script something like C++, how limited are you going to be?This project started because Pascal Script is pretty slow and it didn't function very well on platforms other than Windows(x86).
TC Plugin author who wrote the scriptWFX which executes VBScript was a success because he relied on the VBScript scripting engine, a mature engine that's been used since the beginning of Windows. The only issue I see with scriptWFX is the limitation of VBScript's in terms of:
1. limited out of the box collection of modules
2. not platform independent. Think of modules that were written to work under Linux/Solaris/Unix. They can also work under Windows (most of them) if Python were to be used.
Python already provides the scripting engine to be used as part of applications to extend their functionality. The question is, why bother reinventing the wheel when it already exists?
Forget about trying to fork a scritping language out of a compiled one and stick to using a mature, well-known one. Very simple.
Glad you asked. Plugin support will give you the enhanced look and feel that TC offers all within the panels. I can think of many examples but to name a few:
1. Content plugins. Quick easy to setup content plugins that would parse even the most complicated files, for example packet files from tcpdump if you know what I'm talking about.
2. File System plugins. In less than 30 lines of code, you can write a malware scanner that would scan each file as it loads against a well known malware database. These scanners specialize in malware detection where most Anti-viruses fail.
3. File system plugins. Metadata extraction of various files that can be extended. For example, in less than 20 lines of python code you can write a PDF metadata extractor.
4. Lister plugins. Imagine a doc file contains macro and you're afraid to open it. You can write a listen plugin in python and use the famous OleFileIO module to check whether the doc file has embedded macros in it. You can even extend the plugin to show you the macro code before opening it all in less than 20 lines of code.
I can give you another 20 if you want examples but 4 should be sufficient in my opinion.
The problem here is that there is limitation with what can get produced in terms of plugins. To write a plugin for any of the mentioned bullets above, it really takes time, effort, and lots of testing when they get written in a compiled non-managed languages such as Delphi, C, and C++. After all, many plugins are free and authors tend to be skeptical when it comes to writing plugins of these wide requirements.
Just to let you know, the code for the above bullets exists and in less than 30 lines of code. Tons and tons of modules exist for Python. Just think the millions of Python developers that could come up with an extraordinary number of plugins if there was a good support for it.
1. Content plugins. Quick easy to setup content plugins that would parse even the most complicated files, for example packet files from tcpdump if you know what I'm talking about.
2. File System plugins. In less than 30 lines of code, you can write a malware scanner that would scan each file as it loads against a well known malware database. These scanners specialize in malware detection where most Anti-viruses fail.
3. File system plugins. Metadata extraction of various files that can be extended. For example, in less than 20 lines of python code you can write a PDF metadata extractor.
4. Lister plugins. Imagine a doc file contains macro and you're afraid to open it. You can write a listen plugin in python and use the famous OleFileIO module to check whether the doc file has embedded macros in it. You can even extend the plugin to show you the macro code before opening it all in less than 20 lines of code.
I can give you another 20 if you want examples but 4 should be sufficient in my opinion.
The problem here is that there is limitation with what can get produced in terms of plugins. To write a plugin for any of the mentioned bullets above, it really takes time, effort, and lots of testing when they get written in a compiled non-managed languages such as Delphi, C, and C++. After all, many plugins are free and authors tend to be skeptical when it comes to writing plugins of these wide requirements.
Just to let you know, the code for the above bullets exists and in less than 30 lines of code. Tons and tons of modules exist for Python. Just think the millions of Python developers that could come up with an extraordinary number of plugins if there was a good support for it.
Now and again I have the impression that Python is a very promising scripting language that I should get to know better. Please show the uninitiated the existing 30-liners for any two of the examples above like this:billiebub wrote:Just to let you know, the code for the above bullets exists and in less than 30 lines of code.
Code: Select all
01
02
..
30
Code: Select all
01
02
..
30
-
ghisler(Author)
- Site Admin
- Posts: 50930
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
No, currently I do not plan any scripting limited to just Total Commander. Windows is a multi-tasking environment. Therefore I think that it doesn't make sense to have a separate scripting tool in each program. Better use a tool like AutoHotkey.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
I think you're missing the point. Plugins that can be scripted rather than compiled will add the potential for having more variety of plugins. This has nothing to do with Windows being multi-tasked and no it does not make sense to script all programs but Total Commander provides plugin capabilities and the simple thing to ask is, would it make sense to script plugins or have the choice to rather than create native ones all the time?
You are missing the point.billiebub wrote:I think you're missing the point. Plugins that can be scripted rather than compiled will add the potential for having more variety of plugins. This has nothing to do with Windows being multi-tasked and no it does not make sense to script all programs but Total Commander provides plugin capabilities and the simple thing to ask is, would it make sense to script plugins or have the choice to rather than create native ones all the time?
Using Autohotkey is not having any plugin to be scipted
but just a way to script anything in any program.
No plugin is needed in that case.
You are missing the point that you can already interact with TC in python but C. Ghisler do not want to provide any automation API. And from many discussion in the past, it seems that C. Ghisler want to keep integrity of TC and not opening the box and do not support too much automation.billiebub wrote:I think you're missing the point. Plugins that can be scripted rather than compiled will add the potential for having more variety of plugins. This has nothing to do with Windows being multi-tasked and no it does not make sense to script all programs but Total Commander provides plugin capabilities and the simple thing to ask is, would it make sense to script plugins or have the choice to rather than create native ones all the time?
For now:
You can use Windows message to send any TC command if you need parameters, WM_COPYDATA is also available for CD, EM ....
For a very limited set of message you can also get some information from TC with copydata "callback".
You can also get a lot of info from logs and ini files.
Interacting with user interface is more difficult if you want to cover 64bit version.
Autohottkey seems to be the most popular automation tool in this forum. But you are free to use your preferred programming language to do what is currently allowed.
