Page 1 of 1 1
Topic Options
#191731 - 2009-01-08 07:56 PM Method to "gobble" the command line
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
I don't know if there's a workaround for this, but since we're in a fresh beta, it might be easy to fix.

If I run the command
 Code:
kix32 myscript.kix filename -switch
the code will run properly, and then kix will complain "ERROR : failed to find/open script [filename]!" It recognizes switches with "-" or "/" properly.

The simple workaround is to use Quit instead of Exit, but that won't work for me. I have a command-line tool that takes a simple name (no leading - or /) argument followed by 0 or more switches. This script does complex processing, and has numerous switches. There are two front-end scripts - a GUI and a sequencer. The GUI simply collects screen settings and calls the core script with the assembled parameters. The sequencer calls the core script several times, once for each simple name argument. As such, I need to return control to the higher-level Kix scripts, so can't use Quit in the core script.

At this time, I use a batch file that calls the core script with $ARG1=%1 and $ARG2=%ARGS%. The front-end scripts call the bat file instead of the core script directly. I'd like to move away from batch file front-ends and use GetCommandLine in the core script.

What would work really well with GetCommandLine is a corresponding FlushCommandLine command. It would simply remove all arguments from the command line after the current script name (using GetCommandLine(1), any element above 1 would be cleared.) Thus, if you ran
 Code:
kix32.exe script1 script2
it would work properly since script1 doesn't mess with the commandline. However, if you ran
 Code:
kix32 script1 filename
and script1 ran the FlushCommandLine command, it would exit and Kix would not try to execute "filename" as if it were a script.

Thanks for the consideration.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#191733 - 2009-01-08 11:09 PM Re: Method to "gobble" the command line [Re: Glenn Barnas]
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
hmm...
I would like to see multiscript commandline disabled.

but the flushcommandline would work too...
_________________________
!

download KiXnet

Top
#191735 - 2009-01-09 04:17 AM Re: Method to "gobble" the command line [Re: Lonkero]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Yeah - that would work.. I've never called more than one script on a command line, but changing that could break things for others that do use that feature.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#191736 - 2009-01-09 04:37 AM Re: Method to "gobble" the command line [Re: Glenn Barnas]
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
I'd be interested in know if anyone has ever used that... I can say not once have I ever specified more than one script.
Top
#191737 - 2009-01-09 09:07 AM Re: Method to "gobble" the command line [Re: Allen]
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
me neither.
if second script is required, it's started by the first.

if multiple scripts are required... well, there never just is such situation.
_________________________
!

download KiXnet

Top
#191738 - 2009-01-09 10:16 AM Re: Method to "gobble" the command line [Re: Lonkero]
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Some *nix tools to use a "--" switch to mean "Ignore the rest of the line". For example:
 Code:
kix32.exe -f myscript.kix -- -myswitch file1 file2 file3 ...


In this example everything after the "--" is available via the command line macro, but is ignored by the interpreter.

Maybe a SetOption() would do as an easy to implement alternative.
 Code:
$=SetOption("SingleScript","ON")


Although just thinking about it now, maybe full control over the command line processing would be cool.

How about being able to chain to a new script on exit? Or being able to restart your script with different command line parameters on exit? The same mechanism would be used to swallow the command line parameters.

Top
#191740 - 2009-01-09 12:03 PM Re: Method to "gobble" the command line [Re: Richard H.]
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
I think I have actually suggested something like -- before...

also piping support has been requested multiple times.
_________________________
!

download KiXnet

Top
#196589 - 2009-11-05 05:16 PM Re: Method to "gobble" the command line [Re: Lonkero]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
I want to bump this up again, since it's really beginning to affect my ability to use Kix in complex applications.

The fact that Kix32 recognizes both "/" and "-" as argument lead-ins prevents the use of any argument that begins with reserved parameters.

For example, if I choose to use "-Dump" as a script argument to dump some data, Kix32 interprets it as "/D", resulting in the script running in debug mode and not performing the dump. Clearly "-Dump" and "/D" are different, so there's no real reason for Kix to "get in the way". I'm using "+Dump" and "+Hotfix" parameters in some scripts, but the "+" is "unnatural". Using "--dump" works, but is unnatural for users not familiar with Unix/Posix command lines. I can't tell you how many times I've gotten calls from users that ran "script -hotfix:package6" and got a strange (and unrelated to their task) help message instead of having the hotfix package applied.

There's also the issue of arguments being interpreted as secondary script names. This causes problems unless you remember to terminate / exit your script with Quit to prevent further script execution. The general concensus was that this is a rarely used feature, although we don't necessarily want a change that will break functionality.

I'd really like to see the following changes to Kix for the next release, which would significantly improve handling of command-line arguments. Nearly 80% of my scripts REQUIRE arguments, and nearly all accept arguments.
  • Restrict Kix to strict native interpretation of command line parameters, so the alternate can be used by the script itself. For example, any of the following:
    • Kix only responds to "/" parameters - "/d" and not "-d" for debug
    • Kix qualifies the parameters it responds to - "/d" for debug, but "/demand" is ignored.
    • Since Kix args are used less often than script args, how about requiring them to be "spelled-out", as in /debug, /tokenize, /flushcache, /unlock, /?, /help, and /rpcsearch?
    • Require Kix to recognize its arguments with "--" is another (my favorite) approach, which allows all "/" or "-" arguments to pass to the scripts unmolested.
  • Implementation of a method to clear the command line, so that further processing of arguments as script names is not done. This can be a ClearCommandLine() function, or an optional parameter added to GetCommandLine(). I'd prefer the latter, so that if I'm using GetCommandLine() I can clear it at the same time. Using
     Code:
    $aCmdLine = GetCommandLine(1,1)
    would return the command line as an array and flush it, causing further calls to GetCommandLine() to return nothing, and preventing Kix from parsing script args as script names.
I'm thinking that there should be some kind of middle ground that allows simple and uncomplicated use of command-line arguments and parameters.

Thanks!

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#196595 - 2009-11-05 09:59 PM Re: Method to "gobble" the command line [Re: Glenn Barnas]
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Can't you escape the character Glenn since I'm sure you're using a batch file to kick it off anyways. Then you can use or not use when and where you want in the batch file.

something like "\"

Top
#196601 - 2009-11-06 02:50 PM Re: Method to "gobble" the command line [Re: NTDOC]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
Nope - I have tried to avoid using scripts to call scripts whenever possible. At this point, I only have two Kix scripts that have BAT front ends, and one that is a bat file. Everywhere that we use Kix for admin tasks, .KIX is associated with Kix32, so I just run "script" and script.kix executes with all args passed. Of course, this is only on admin systems and servers, not in general population.

My SWDIST Install command has BAT front end, because it assumes that no special tools are available on the computer where the software is being installed. The BAT file calls kix from the install root and simply passes the args (%*) to the kix script, which then parses them. The other one is KGen, which actually IS a .BAT file
 Code:
;@Echo Off
;kix32.exe "%~f0" %*
;Goto END
<kix script goes here>
;:END
Nearly all of my scripts are tokenized, so tricks like this one won't work everywhere. The point is - it should not be difficult to add ONE of the command-line suggestions to Kixtart to provide a fairly significant enhancement to the scripting engine.

I guess the other difference is that the casual user would use Kix for login scripts.. a more savvy user would extend Kix into their admin toolkit. I actually try to push the limits and have several full-blown enterprise applications written in Kix/KF. Many of these are freely available from my web site.

Some of the most widely deployed tools are
  • SWDIST - a software management system that provides command line and GUI tools to install any type of software, service pack, and patch to any Windows computer without the need for any software on the target systems. It supports automated maintenance, distributed installation (multi-server synchronization and identification of the nearest server), and full reporting. Only two BAT files here to avoid the need of prerequisite software.
  • tsadm - the Task Scheduler Admin tool, a KixForms GUI that allows simple management of Windows scheduled tasks, deployment of tasks to multiple systems, and copy/paste of tasks between systems.
  • SWDeploy - An application with two KixForms GUI tools and a Kix service that controls the staging and deployment of web-based applications. Developers drop updated code and a "process control file" onto a share. They can then use the Stage and Deploy tools to deploy their package to a development server to verify the package works as planned. The Software Assurance team then uses the Stage tool to prestage the deployment to QA servers. The Operations team receives the alert from the stage tool and uses the Deploy tool to perform the deployment to QA. If that works, the process is repeated for deployment to Production. Neither the QA or Operations team have direct access to the web servers - the deployment is done by the SWDeploy service, running on a server that has specific network rights and uses the appropriate account for each web environment.
  • MailSig - a suite of tools that create and manage email signatures, providing a standard signature format across the enterprise. The signature generator script uses a BAT to specify Kix, since none of the end-users have Kixtart installed, but the users that manage the various signatures (our largest client has about 14 different sigs across the enterprise) has Kix and KF installed on their workstation. The management tool uses KF.
  • Postprep Command Line (ppcl) - a command line version of the PostPrep GUI used for quick, automated generation of one to hundreds of .KIX or .UDF files. Our entire UDF library is post-prepped and posted to our web site nightly using this tool.
  • SendMail - a Kix-based Windows service that allows email to be sent from any application by simply dropping a formatted INI file into a folder. We use it internally to send mail from our web site, providing a layer of isolation between the web and mail systems.
  • FolderSync - a tool that runs on a scheduled basis and synchronizes folders from one server to another. (this will be posted to the Vault soon)
  • UniSynK - a kix-based Windows service that works with Unison to maintain synchronization between multiple servers. Up to 10 folder structures can be synchronized on each server. Works over LAN or WAN, and can detect and initiate a replication within 60 seconds of the source data being modified.
  • PerfMonManager - a suite of tools to manage Windows PerfMon logging. Allows the user to quickly create, modify, and remove perfmon attributes from logs, performs nightly log rotations, and restarts the log collection after reboots.
  • KGen - a tool that scans defined UDF library folders to generate a list of available UDFs, parses a Kix script, resolves UDF dependencies, generates a target script with all UDF dependencies included, and then (optionally) tokenizes the generated script, copies it to one or more target locations, and performs a sanity check on the finished script to assure that common syntax errors are avoided. It also creates an index of variables (function/line where defined, where first used), and a map of statement pairs so you can quickly identify malformed statements (if w/o endif, for example).
  • HelpDesk - a KixForms-based GUI tool with a client/server model that allows a help-desk technician to view common computer information, manage services, list and kill processes, manage scheduled tasks, view/set the PATH, and perform basic AD Admin tasks like unlock the user's account or reset their password. On a LAN, it communicates to the client with no special software, but on a WAN it can communicate to a special KF-based client (non-gui) using IP Sockets to improve performance. That socket-based client can be used with a command-line tool as well to perform quick queries and perform basic tasks. This client is also being deployed to servers in small datacenters to perform controlled shutdowns for site maintenance or power-failure response.
Most of these either accept command-line arguments or have management tools that do.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
Page 1 of 1 1


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 515 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.06 seconds in which 0.024 seconds were spent on a total of 13 queries. Zlib compression enabled.