Experienced PHP developer would like to code TCL script, but missing sum fundamentals

[mantonio1965]

Hi,

i am trying to code an own script for the ioFTPD server based on TCL. I am coming from PHP and JAVA and after studying o_dogs and neoxeds scripts that i understand the language. But from time to time i stuck with commands like
vfs chattr or readchattr 35 and wonder if these are TCL commands too or something specific io-related.

Anyone experienced can enlighten me where to find kinda knowledge base regarding this server-related TCL coding stuff? I would like to understand these things and to work out own scripts for individual needs that are not covered by the great scripts from o_dog and neoxed. Where did you guys get this knowledge from?

[Hans_]

hey mantonio1965,


http://www.egghelp.org/commands/


http://www.eggheads.org/support/egghtml/1.6.18/tcl-commands.html

http://johoho.eggheads.org/eggdrop/other/guide2tcl.html

;)

[mantonio1965]

Thanks Hans, i'll check these out and get back in case of further questions.

[Yil]

You really need to check out the /doc/iTCL.txt file :) That's where you will find the documentation for the ioFTPD specific extensions to TCL which is referred to as iTCL. Details on things like the "vfs" command, etc are all there. If in doubt about how to do something, just ask. There are LOTS of better ways to do things now than were available when nxTools was written.

[mantonio1965]

Thanks a bunch, guys! :-)

Yil, does this mean, that nxTools functionality was partially ported to ioFTPDs core functionality?

[Yil]

Yes... A lot of what was tricky for nxTools to do is now done in the server and exposed via new TCL calls. In fact, entire features like site open/close, site who, etc are all builtin command now as well. nxTools could only dream of asking the server to get the parsed mountfile, get an actual directory listing with merged dirs, submounts, etc all included. It would be far easier to write a site script now :)

There are actually 2 ways to extend ioFTPD. TCL is clearly the more flexible and powerful method, but you can also use the EXEC module to run any old executable and have it interact with ioFTPD in a limited manner. The real advantage here is you could use php scripts if your problem is simple enough that you don't need features exposed only via TCL. Quite a number of zipscripts from like a decade ago are .exe based and Jeza's new java based archiving code uses it today. Its interface isn't especially well documented anywhere but the commands are !putlog, !vfs:add, !vfs:chattr, !change, !unlock, !newlines, !prefix, !buffer, and !detach which are just commands you can send to the server via stdout that it acts on rather than outputting to the client. Inputs to the executable are via the command line, you'll find them documented in doc/Events.txt, and via the process environment created by /etc/ioftpd.env. It defines a lot of things already, but you can use any ioFTPD cookies (/doc/Cookies.txt) to add more information if what is there already isn't enough. You can always go right to the ioFTPD source code for exact details :)

[mantonio1965]

Wow, that sounds quite amazing. In fact it was easier to me writing a sorting script to my specific needs in php and store the data into a mysql db because this distincts the need to dive into TCL coding specially for io. I thought, TCL was 'the' choice because it is the fastest and only way to do things like that. I should definately check out the docs and see if i can get it. You made me quite hot on it! ;)

[o_dog]

there was a php zipscript written years ago for ioftpd. Worked ok if i remember correctly. but reading and writing to vfs might get tricky in php.

[mantonio1965]

... which is why i'm willing to dive into TCL coding. But it seems, things work very different. Currently i am trying to find out how to trigger events like RNTO just to simulate the manual renaming of a folder. But it seems to me that calling commands like "site rename folder" from within a TCL script is the wrong way. :question:

[o_dog]

site command is commands sent to the ftpserver, does not work within tcl. Use: file rename folder newname

if you want to catch the response: catch {file rename oldname newname} catchvariable

[mantonio1965]

Thanks for that hint. I was digging through your Zipscript to see how things work and to adopt how to manage the code for my goal. Renaming using your solution works. After reading your hint i expected the variable catching the renaming return value would hold the related system event, but i was wrong. It is simply empty.

What i am trying to achive is to call nxTools::\Dupe::UpdateLog, which expects and evaluates a command like DELE, UPLD, MKD, which are all events fired by the server (i guess). This method must update the dupe database after renaming a folder. So i tried two different things.

a) Rename the folder manually -> nxTools::\Dupe::UpdateLog function handles the event
b) after renaming the folder via TCL script call ::nxTools::\Dupe::UpdateLog "RNFR" $release_pwd -> ends up with an error
--- ErrorInfo ---
invalid command name "::nxTools::\Dupe::UpdateLog"
while executing
"::nxTools::\Dupe::UpdateLog "RNFR $release_pwd""
I have no idea, why this method is not available in this script. Also i have no idea how to check if the class/method exists before calling it like in PHP.

NOTE: I escaped ::\D just to prevent this being converted to smileys here. This is actually not how i use it in the script. ;)

[o_dog]

your problem is probably the namespace in nxtools. The best solution would probably be to just add a proc in nxtools, and then call the updatelog with arguments from within the same namespace. Make sure you get the arguments right and to set the paths and pwds right for the nxtools update proc.

[brackebuschtino]

Mhm ... i'm not sure if i got you correctly.

The best solution would probably be to just add a proc in nxtools, and then call the updatelog with arguments from within the same namespace.

Do you mean to implement my sorting as an nxTools function? But then i cannot use some of ioNiNJA's functionality anymore.
If you did not mean this, then i assume i have to call the additional nxTools function from my script which leads me back to the initial problem.

Mabe it is interesting to know that calling

::nxTools::Dupe::SiteUndupe "-d [file tail $pwd]"

from within


proc ::ioNiNJA::get_flac_information {flacfile} {global pwd path args ioNJ uid gid}
proc ::ioNiNJA::get_mp3_information {mp3file} {global ioNJ args pwd path uid gid}


works fine. My own function is at the bottom of this file and using the same function initialization

proc ::ioNiNJA::uncat {} {global ioNJ path pwd args}

The only difference it to call it without a function param. I'm doin' my best to see any difference, but i can't. Mabe you?

[o_dog]

Like I said, namespace. Rename the proc ::ioNiNJA::uncat
to
::nxTools::uncat

that should work within the same namespace. Otherwise you will haveto load nxtools from the tcl file using "source" or "load" maybe, can't remember which. But inclusing it it the same namespace is simpler.

[brackebuschtino]

K, finally it is working through extending command switch

switch -- [lindex $args 0] {
UNCAT { source "../scripts/nxTools/nxDupe.tcl" ; ::ioNiNJA::uncat }
}

This was the easiest solution for the moment. Of course it is not the best regarding decoupling dependencies.

Now i still need the curl.exe to work with https URLs (https://oss.azurewebsites.net/forum/ioftpd/ioftpd/scripting/new-scripts-announces-updates/14768-ioninja-new-post.html) and all will be fine.

Thank you, o_dog! :)

[o_dog]

like i said in the other thread, it should work with https. But if it doesn't all you need to do is replace it with one that does. the other functions should work without a problem if you replace it. But I never got in deep with curl so there might be a switch for https, check the helo ..\ioninja\misc\curl.exr --help
should work otherwise check curl.exe /h

good luck