This is really a comment on "Python in Systems Administration: Part I
-- Better Scripting"
by Cameron Laird.
Reading the article, although I am a fan of Python, I kinda take issue
with the example given. It doesn't seem to fit with the concept of
'many smaller utilities doing one thing well, connected via pipes'
If I had the task of writing a Unix utility to match the GUI Python
example I would prefer to either:
1) save a sorted file listing to a temporary file then use either
$EDITOR or vi to edit the temporary file, and on completion extract
those files mentioned in the temporary file. OR
2) Write a general argument selector in Python that could be imported
in a larger Python prog as a module where its function would be to
display a python list of strings in a GUI and return those selected,
OR when executed as a command, it would display all its arguments in
the order given, and return those selected. The command line versions
could have options to sort the input and to either return space
separated or newline separated versions of its output (and maybe CSV
too).
The advantages of the first is that you would use the users $EDITOR.
The user will be on familiar territory, and not much extra programming
is needed.
The advantages of 2 are that you end up with a python module/script
that is *re-usable* both in a Python program and as a command line
script in the tradition of Unix utilities.
Such Python module/scripts if collected on a central web site could
form a useful resource for System Administrators.
Whoops, I almost forgot, The third way might be to look up utilities
for adding GUIs to command line utilities and using those. (e.g.
kaptain at http://kaptain.sourceforge.net )
To summarize then, using similar reasons for writing a script for the
simple tar extraction; when you write your Python version you might
want to modularize reusable components but also make that Python
module a command line utility itself.
Cheers, Pad.
-- Better Scripting"
by Cameron Laird.
Reading the article, although I am a fan of Python, I kinda take issue
with the example given. It doesn't seem to fit with the concept of
'many smaller utilities doing one thing well, connected via pipes'
If I had the task of writing a Unix utility to match the GUI Python
example I would prefer to either:
1) save a sorted file listing to a temporary file then use either
$EDITOR or vi to edit the temporary file, and on completion extract
those files mentioned in the temporary file. OR
2) Write a general argument selector in Python that could be imported
in a larger Python prog as a module where its function would be to
display a python list of strings in a GUI and return those selected,
OR when executed as a command, it would display all its arguments in
the order given, and return those selected. The command line versions
could have options to sort the input and to either return space
separated or newline separated versions of its output (and maybe CSV
too).
The advantages of the first is that you would use the users $EDITOR.
The user will be on familiar territory, and not much extra programming
is needed.
The advantages of 2 are that you end up with a python module/script
that is *re-usable* both in a Python program and as a command line
script in the tradition of Unix utilities.
Such Python module/scripts if collected on a central web site could
form a useful resource for System Administrators.
Whoops, I almost forgot, The third way might be to look up utilities
for adding GUIs to command line utilities and using those. (e.g.
kaptain at http://kaptain.sourceforge.net )
To summarize then, using similar reasons for writing a script for the
simple tar extraction; when you write your Python version you might
want to modularize reusable components but also make that Python
module a command line utility itself.
Cheers, Pad.
Comment