I will say this:
Emacs with slime is much nicer than perl+vi.
Perl so far is hell because it seems to lack rhyme or reason. Common
lisp and scheme at least seem to have a system that is minimalistic
and flexible. Just the operator precedence and the weird syntax for
forming arrays in perl annoys me. I can only hope that common lisp is
not hamstrung by dealing with files and unix in an inconvenient manner
once I get that far... It is amazing the pressure from linux admin
peers to not go on with lisp. I don't get why they even give a sh--..
On Oct 23, 1:54 pm, gavino <·········@gmail.com> wrote:
> I will say this:
>
> Emacs with slime is much nicer than perl+vi.
>
> Perl so far is hell because it seems to lack rhyme or reason. Common
> lisp and scheme at least seem to have a system that is minimalistic
> and flexible. Just the operator precedence and the weird syntax for
> forming arrays in perl annoys me. I can only hope that common lisp is
> not hamstrung by dealing with files and unix in an inconvenient manner
> once I get that far... It is amazing the pressure from linux admin
> peers to not go on with lisp. I don't get why they even give a sh--..
All languages are hell. C hasn't figured out how to copy strings
after two tries.
Perl array syntax annoys you? Wait til you get to "0 but true".
--S
On Oct 23, 4:30 pm, smallpond <·········@juno.com> wrote:
> Perl array syntax annoys you? Wait til you get to "0 but true".
Lists are apparently arrays in Perl. But they can also be hash-tables.
The one thing that really bugs me about Perl arrays is that you can't
have arrays of arrays without using references.
-Rudolf
(message (Hello 'OMouse)
(you :wrote :on '(Wed, 24 Oct 2007 04:42:59 -0000))
(
??>> Perl array syntax annoys you? Wait til you get to "0 but true".
O> Lists are apparently arrays in Perl. But they can also be hash-tables.
O> The one thing that really bugs me about Perl arrays is that you can't
O> have arrays of arrays without using references.
from the perllol:
@AoA = (
[ "fred", "barney" ],
[ "george", "jane", "elroy" ],
[ "homer", "marge", "bart" ],
);
print $AoA[2][2];
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy")
On Oct 24, 8:56 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> (message (Hello 'OMouse)
> (you :wrote :on '(Wed, 24 Oct 2007 04:42:59 -0000))
> (
>
> ??>> Perl array syntax annoys you? Wait til you get to "0 but true".
>
> O> Lists are apparently arrays in Perl. But they can also be hash-tables.
>
> O> The one thing that really bugs me about Perl arrays is that you can't
> O> have arrays of arrays without using references.
>
> from the perllol:
>
> @AoA = (
> [ "fred", "barney" ],
> [ "george", "jane", "elroy" ],
> [ "homer", "marge", "bart" ],
> );
> print $AoA[2][2];
It's still an inconsistent syntax. The comma creates a list and the
brackets do nothing really. The square brackets I assume refer to a
reference of whatever object is given to them. Why can't I do:
@blah = (("fred", "barney"), ("george" "jane" ...));
Or
@blah = [["fred", "barney"], ["george" "jane" ...]];
?
-Rudolf
On Oct 23, 12:54 pm, gavino <·········@gmail.com> wrote:
> I will say this:
>
> Emacs with slime is much nicer than perl+vi.
>
> Perl so far is hell because it seems to lack rhyme or reason. Common
> lisp and scheme at least seem to have a system that is minimalistic
> and flexible. Just the operator precedence and the weird syntax for
> forming arrays in perl annoys me. I can only hope that common lisp is
> not hamstrung by dealing with files and unix in an inconvenient manner
> once I get that far... It is amazing the pressure from linux admin
> peers to not go on with lisp. I don't get why they even give a sh--..
Why are you learning Perl? Perl 6 is taking forever to be released,
and Ruby/Python are _much_ better choices in my honest opinion.
On Oct 23, 6:54 pm, gavino <·········@gmail.com> wrote:
> I will say this:
>
> Emacs with slime is much nicer than perl+vi.
>
> Perl so far is hell because it seems to lack rhyme or reason. Common
> lisp and scheme at least seem to have a system that is minimalistic
> and flexible. Just the operator precedence and the weird syntax for
> forming arrays in perl annoys me.
I think the languages are really very different animals. Perl is
basically a natural language, and it has all the weirdness that
natural languages have (I mean: just what *are* the rules for
possessive "'s" in English?). But Perl is just the king of "I have
this bit of crap and I need to feed it to that bit of crap, while
interfacing with this other bit of crap" on Unix. But you have to
beware of dropping your "h"s.
Lisp (CL) is, well, a natural language too, but it's like medieval
Latin to Perl's cockney. You'd not want to do the stuff you do in
Perl in it (though people try), but if you have some complicated
logical argument (preferably involving reasoning about angels on
pinheads), then CL is unparalleled.
The language wars are just so boring, actually. Just use the
appropriate one.
On Oct 23, 10:54 am, gavino <·········@gmail.com> wrote:
> I will say this:
>
> Emacs with slime is much nicer than perl+vi.
>
> Perl so far is hell because it seems to lack rhyme or reason.
that's the way it seemed to me when i was putting perl first.
Now i am putting lisp first, and i see the rhyme and reason of
perl is mostly since perl5.0 borrowed from lisp !
i like to read, and all the perl books come from one place.
but not so with lisp.
it seems perl crowd expects you to be a perl expert specialist.
lisp crowd knows better. you have to be realistic.
but lisp is pretty fun and also interesting. perl is interesting but
not so much fun sometimes.
i have perl6 going in three forms, but i was so stalled in learning
it, i went back to lisp.
i am glad you pick the same two languages as me !! well maybe like
me you had tried others before and were disappointed.
what perl and lisp have in common ?
i have great hopes for perl6 as the first new computer language
of the century. the going is slow because everything is...
at least from my point of view this is the decade of repeating
the last one or something...
well tired now so have to say more next times, except for
one thing
On LISP is a great book !
> lisp and scheme at least seem to have a system that is minimalistic
> and flexible. Just the operator precedence and the weird syntax for
> forming arrays in perl annoys me. I can only hope that common lisp is
> not hamstrung by dealing with files and unix in an inconvenient manner
> once I get that far... It is amazing the pressure from linux admin
> peers to not go on with lisp. I don't get why they even give a sh--..
On Oct 23, 7:54 pm, gavino <·········@gmail.com> wrote:
> I will say this:
>
> Emacs with slime is much nicer than perl+vi.
>
> Perl so far is hell because it seems to lack rhyme or reason. Common
> lisp and scheme at least seem to have a system that is minimalistic
> and flexible. Just the operator precedence and the weird syntax for
> forming arrays in perl annoys me. I can only hope that common lisp is
> not hamstrung by dealing with files and unix in an inconvenient manner
> once I get that far... It is amazing the pressure from linux admin
> peers to not go on with lisp. I don't get why they even give a sh--..
Hmm, common lisp is minimalistic .. doesnt look minimalistic to me.
btw. it's unlikely that someone who cant understand and use perl data
structures ('cant' != 'dont want to') will really learn and understand
common lisp
btw. dont try to use common lisp for everyday perl/ruby unix task
From: Kamen TOMOV
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <uejfkny55.fsf@cybuild.com>
On Wed, Oct 24 2007, ······@gmail.com wrote:
> Hmm, common lisp is minimalistic .. doesnt look minimalistic to me.
With the part of the language I know I can create applications so I'd
argue it is minimalistic. Your knowledge could grow with the size of
the application.
> btw. it's unlikely that someone who cant understand and use perl
> data structures ('cant' != 'dont want to') will really learn and
> understand common lisp
What's the relation? Perl is neither prerequisite, nor it should
be.
> btw. dont try to use common lisp for everyday perl/ruby unix task
>
No, on the contrary, go for it - it's fine as far as the language
goes, but you should also take into account your bosses' opinion.
--
�����
On Oct 24, 8:52 pm, Kamen TOMOV <·····@cybuild.com> wrote:
> What's the relation? Perl is neither prerequisite, nor it should
> be.
I didnt say that perl is prerequisite, i'm just saying that if you are
not clever enough to understand perl data structures (that is just one
example), then it's unlikely that you will understand common lisp.
I dont now cases where someone fail to catch perl or ruby and then
successfully switched to common lisp.
> No, on the contrary, go for it - it's fine as far as the language
> goes, but you should also take into account your bosses' opinion.
There is no reason to insist using CL in every possible situation if
there is better tool (except if you want to impress someone)
From: Kamen TOMOV
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <u640v8v9e.fsf@cybuild.com>
On Thu, Oct 25 2007, ······@gmail.com wrote:
> On Oct 24, 8:52 pm, Kamen TOMOV <·····@cybuild.com> wrote:
>> What's the relation? Perl is neither prerequisite, nor it should
>> be.
> I didnt say that perl is prerequisite, i'm just saying that if you
> are not clever enough to understand perl data structures (that is
> just one example), then it's unlikely that you will understand
> common lisp. I dont now cases where someone fail to catch perl or
> ruby and then successfully switched to common lisp.
OK.
>> No, on the contrary, go for it - it's fine as far as the language
>> goes, but you should also take into account your bosses' opinion.
> There is no reason to insist using CL in every possible situation if
> there is better tool (except if you want to impress someone)
>
Are you trying to say that there is a better tool than Lisp in c.l.l.?
There's no better programming language as far as we know so you better
have a *good* reasoning 'cause otherwise it would be laaame
assertion.
If you had said that Lisp is not such a good idea because of the
people factor (co-workers and/or management) that might have been
fine, but you are not saying that. You are saying that Perl and
Ruby (?!) is a better tool for system administration.
--
�����
On Oct 25, 4:15 am, Kamen TOMOV <·····@cybuild.com> wrote:
> On Thu, Oct 25 2007, ······@gmail.com wrote:
> > On Oct 24, 8:52 pm, Kamen TOMOV <·····@cybuild.com> wrote:
> >> No, on the contrary, go for it - it's fine as far as the language
> >> goes, but you should also take into account your bosses' opinion.
> > There is no reason to insist using CL in every possible situation if
> > there is better tool (except if you want to impress someone)
>
> Are you trying to say that there is a better tool than Lisp in c.l.l.?
> There's no better programming language as far as we know so you better
> have a *good* reasoning 'cause otherwise it would be laaame
> assertion.
>
> If you had said that Lisp is not such a good idea because of the
> people factor (co-workers and/or management) that might have been
> fine, but you are not saying that. You are saying that Perl and
> Ruby (?!) is a better tool for system administration.
I don't recall someone asserting that Lisp is better suited for
sysadmin scripts than Perl or Ruby before, so I have to admit I'm
curious. Would you be willing to share a small Lisp script or two that
you've used for sysadmin types of tasks?
For example, here's a little script to monitor a file on a remote
system for changes by periodically executing a remote command via ssh
and comparing the data received and popping up an X window dialog when
a change is detected.
Since I'm fluent in Ruby and only learning Lisp, the former was the
natural choice for me at this time, but I would think that even after
I gain experience in Lisp, this sort of "quick little hack" would
still be easier in Ruby, but I'd like to keep an open mind. What would
this look like in Lisp?
def monitor_remote_file user, host, filepath, frequency=300
# A string within backtick ( ` ) characters is sent to the
# operating system and evaluates to the output of the cmd
cmd = lambda { `ssh ·······@#{host} tail #{filepath}` }
data = cmd.call
while true
sleep frequency
if (new_data = cmd.call) != data
# invoke the block that was passed to this function
yield
data = new_data
end
end
end
require 'date'
monitor_remote_file('bob', '10.0.0.1', '/production.log', 600) do
# code between do ... end is a "block" of code that is passed to
the
# monitor_remote_file function, so when the function invokes "yield"
# we'll popup an X window notification
`xmessage -center -title MODIFIED "File modified at
#{DateTime.now}"`
end
On Oct 25, 8:13 am, Brian Adkins <···········@gmail.com> wrote:
> I don't recall someone asserting that Lisp is better suited for
> sysadmin scripts than Perl or Ruby before, so I have to admit I'm
> curious. Would you be willing to share a small Lisp script or two that
> you've used for sysadmin types of tasks?
>
> For example, here's a little script to monitor a file on a remote
> system for changes by periodically executing a remote command via ssh
> and comparing the data received and popping up an X window dialog when
> a change is detected.
>
> Since I'm fluent in Ruby and only learning Lisp, the former was the
> natural choice for me at this time, but I would think that even after
> I gain experience in Lisp, this sort of "quick little hack" would
> still be easier in Ruby, but I'd like to keep an open mind. What would
> this look like in Lisp?
>
> def monitor_remote_file user, host, filepath, frequency=300
> # A string within backtick ( ` ) characters is sent to the
> # operating system and evaluates to the output of the cmd
> cmd = lambda { `ssh ·······@#{host} tail #{filepath}` }
> data = cmd.call
> while true
> sleep frequency
> if (new_data = cmd.call) != data
> # invoke the block that was passed to this function
> yield
> data = new_data
> end
> end
> end
>
> require 'date'
>
> monitor_remote_file('bob', '10.0.0.1', '/production.log', 600) do
> # code between do ... end is a "block" of code that is passed to
> the
> # monitor_remote_file function, so when the function invokes "yield"
> # we'll popup an X window notification
> `xmessage -center -title MODIFIED "File modified at
> #{DateTime.now}"`
> end
Here's a version that stays true to the style of the original, and
should be portable if you've got TRIVIAL-SHELL and LOCAL-TIME
installed :
(defun monitor-remote-file (user host filepath thunk
&optional (frequency 300))
(flet ((tail-remote-file ()
(trivial-shell:shell-command
(format nil "ssh ··@~A tail ~A" user host filepath))))
(let ((data (tail-remote-file)))
(loop
:for new-data = (tail-remote-file)
:do
(unless (equalp new-data data)
(setf data new-data)
(funcall thunk))
(sleep frequency)))))
(monitor-remote-file "drewc" "tech.coop" "/tmp/test"
(lambda ()
(trivial-shell:shell-command
(format nil "xmessage -center -title MODIFIED \"Modified at ~A
\""
(local-time:now))))
600)
That is a very literal translation of the ruby version. The only real
difference is that we have to explicitly pass the thunk in, rather
than yield to a block,
Personally, i would not use ruby or lisp for this job. I prefer to
tackle shell scripting tasks with .. wait for it .. the shell. /bin/sh
is great at such things. If a script gets too large or complex to
program in sh, then it's Common Lisp to the rescue.
CL might not have a tight integration with unix, but SBCL has bindings
for just about every POSIX function out there, and with cl-ppcre it's
a better Perl than Perl.
Cheers,
drewc
Brian Adkins <···········@gmail.com> writes:
> Since I'm fluent in Ruby and only learning Lisp, the former was the
> natural choice for me at this time, but I would think that even after
> I gain experience in Lisp, this sort of "quick little hack" would
> still be easier in Ruby, but I'd like to keep an open mind. What would
> this look like in Lisp?
>
> def monitor_remote_file user, host, filepath, frequency=300
> # A string within backtick ( ` ) characters is sent to the
> # operating system and evaluates to the output of the cmd
> cmd = lambda { `ssh ·······@#{host} tail #{filepath}` }
> data = cmd.call
> while true
> sleep frequency
> if (new_data = cmd.call) != data
> # invoke the block that was passed to this function
> yield
> data = new_data
> end
> end
> end
>
> require 'date'
>
> monitor_remote_file('bob', '10.0.0.1', '/production.log', 600) do
> # code between do ... end is a "block" of code that is passed to
> the
> # monitor_remote_file function, so when the function invokes "yield"
> # we'll popup an X window notification
> `xmessage -center -title MODIFIED "File modified at
> #{DateTime.now}"`
> end
In Clisp this is a bit longer but contains mostly reusable functions. I
really can't check this since my ssh requires a password. My rsh
variant works fine. Most my utility scripts seem to grow or change with
time, and I find refactoring very easy in lisp.
(defun iso-date (&optional (time (get-universal-time)))
"Return iso format date string given universal time"
(multiple-value-bind (sec min hour day month year)
(decode-universal-time time)
(declare (ignore sec))
(format nil "~d-~2,'0d-~2,'0d ~2,'0d:~2,'0d"
year month day hour min)))
(defun alarm ()
"Pop up message with failure time"
(ext:shell (format
nil
"xmessage -center -title MODIFIED \"File modified at ~a\""
(iso-date))))
(defun get-response (command)
"Return output from command as list of strings"
(with-open-stream (stream (ext:make-pipe-input-stream command))
(loop for line = (read-line stream nil)
while line
collect line)))
(defun equal-lines-p (alines blines)
"True if lists of lines match"
(and (= (length alines) (length blines))
(every #'string= alines blines)))
(defun watch-file (user host file wait)
(let* ((command (format nil "ssh ··@~a tail ~a </dev/null 2>/dev/null"
user host file))
(ref-lines (get-response command)))
(loop
(sleep wait)
(let ((now-lines (get-response command)))
(unless (equal-lines-p now-lines ref-lines)
(alarm)
(setf ref-lines now-lines))))))
(watch-file "bob" "10.0.0.1" "/production.log" 10)
--
Barry Fishman
On Oct 25, 3:46 pm, Barry Fishman <·············@acm.org> wrote:
> Brian Adkins <···········@gmail.com> writes:
> > Since I'm fluent in Ruby and only learning Lisp, the former was the
> > natural choice for me at this time, but I would think that even after
> > I gain experience in Lisp, this sort of "quick little hack" would
> > still be easier in Ruby, but I'd like to keep an open mind. What would
> > this look like in Lisp?
>
> > def monitor_remote_file user, host, filepath, frequency=300
> > # A string within backtick ( ` ) characters is sent to the
> > # operating system and evaluates to the output of the cmd
> > cmd = lambda { `ssh ·······@#{host} tail #{filepath}` }
> > data = cmd.call
> > while true
> > sleep frequency
> > if (new_data = cmd.call) != data
> > # invoke the block that was passed to this function
> > yield
> > data = new_data
> > end
> > end
> > end
>
> > require 'date'
>
> > monitor_remote_file('bob', '10.0.0.1', '/production.log', 600) do
> > # code between do ... end is a "block" of code that is passed to
> > the
> > # monitor_remote_file function, so when the function invokes "yield"
> > # we'll popup an X window notification
> > `xmessage -center -title MODIFIED "File modified at
> > #{DateTime.now}"`
> > end
>
> In Clisp this is a bit longer but contains mostly reusable functions.
Thanks for the example; it's a good starting point for me to explore
this sort of thing in Lisp. When I remove comments and blank lines, I
get 15 lines, 415 chars for mine and 30 lines, 1,212 chars for yours,
so I'm not sure if that qualifies for "a bit longer" :) I do agree
about the reusable functions though, and when you take that into
consideration, it's pretty close, so I find the example encouraging.
I wonder if macros can help with getting the equivalent of:
`xmessage "file modified at #{DateTime.now}"`
I realize that 'format' is quite powerful, but it would be nice to
have something more concise at times. In particular, I find the
following features attractive:
1) Evaluation of the contents of #{...} inserted into the string
2) Allowing different string delimiters (i.e. other than ") to
minimize escaping
I don't think either of those would be difficult in Lisp. Are you
aware of any functions or macros that address those?
The syntax of the backticks for automatically sending a command to the
shell isn't that important to me, I'd be fine with something like:
(shell |xmessage "file modified at #{(format_time)}"|)
Would a reader macro be necessary to allow choice of string delimiters
such as '|' above to avoid escaping \" ? It's not a big deal in this
example, but some scenarios require much escaping.
On Oct 25, 2:26 pm, Brian Adkins <···········@gmail.com> wrote:
> On Oct 25, 3:46 pm, Barry Fishman <·············@acm.org> wrote:
>
>
> > In Clisp this is a bit longer but contains mostly reusable functions.
>
> Thanks for the example; it's a good starting point for me to explore
> this sort of thing in Lisp. When I remove comments and blank lines, I
> get 15 lines, 415 chars for mine and 30 lines, 1,212 chars for yours,
> so I'm not sure if that qualifies for "a bit longer" :)
Mine's 13 lines, 418 chars. The char count could be reduced as i'm
using descriptive identifiers, but it's still at par with the ruby
version.
>
> I wonder if macros can help with getting the equivalent of:
> `xmessage "file modified at #{DateTime.now}"`
>
> I realize that 'format' is quite powerful, but it would be nice to
> have something more concise at times. In particular, I find the
> following features attractive:
> 1) Evaluation of the contents of #{...} inserted into the string
> 2) Allowing different string delimiters (i.e. other than ") to
> minimize escaping
>
> I don't think either of those would be difficult in Lisp. Are you
> aware of any functions or macros that address those?
You are looking for cl-interpol : http://weitz.de/cl-interpol/
Example:
* (let ((a 42))
#?"foo: \xC4\N{U with diaeresis}\nbar: ${a}")
"foo: ��
bar: 42"
Cheers,
drewc
>
> The syntax of the backticks for automatically sending a command to the
> shell isn't that important to me, I'd be fine with something like:
> (shell |xmessage "file modified at #{(format_time)}"|)
>
> Would a reader macro be necessary to allow choice of string delimiters
> such as '|' above to avoid escaping \" ? It's not a big deal in this
> example, but some scenarios require much escaping.
On Oct 25, 7:19 pm, Drew Crampsie <·············@gmail.com> wrote:
> You are looking for cl-interpol :http://weitz.de/cl-interpol/
Thanks, that's excellent. A lot to digest, but I've bookmarked it for
future reference.
Brian Adkins <···········@gmail.com> writes:
> Thanks for the example; it's a good starting point for me to explore
> this sort of thing in Lisp. When I remove comments and blank lines, I
> get 15 lines, 415 chars for mine and 30 lines, 1,212 chars for yours,
> so I'm not sure if that qualifies for "a bit longer" :) I do agree
> about the reusable functions though, and when you take that into
> consideration, it's pretty close, so I find the example encouraging.
>
> I wonder if macros can help with getting the equivalent of:
> `xmessage "file modified at #{DateTime.now}"`
>
> I realize that 'format' is quite powerful, but it would be nice to
> have something more concise at times. In particular, I find the
> following features attractive:
> 1) Evaluation of the contents of #{...} inserted into the string
> 2) Allowing different string delimiters (i.e. other than ") to
> minimize escaping
>
> I don't think either of those would be difficult in Lisp. Are you
> aware of any functions or macros that address those?
>
> The syntax of the backticks for automatically sending a command to the
> shell isn't that important to me, I'd be fine with something like:
> (shell |xmessage "file modified at #{(format_time)}"|)
>
> Would a reader macro be necessary to allow choice of string delimiters
> such as '|' above to avoid escaping \" ? It's not a big deal in this
> example, but some scenarios require much escaping.
You might look at scsh for ways one might express these kinds of shell
like shortcuts.
I guess I don't get that enthusiastic about the kind of text compression
produced by backticks and shell like ${name} expansions. These just
reduce keystrokes in doing low level type operations. In a sense, they
can be counter-productive in that they make repeated use of low level
operations more palatable. I'm more interest in collecting higher level
components that I can use in building utilities.
Maybe I'm biased because of poor eyesight, and not wanting a major
part of interpreting a valid program resting on distinguishing between a
forward and back tick, or the difference between a comma and a dot.
To me 15 lines vs 30 lines isn't that important. Some verbosity in very
short scripts is less of a problem than needing to be skillful in
another language just to deal with these simple situations. What does
concern me is what happens as scripts grow to hundreds of lines. As
programs get larger, Common Lisp features become more and more
important. Things like exception handling and building complex data
structures seem easier (at least to me) in Common Lisp.
The only exceptions are for very simple scripts which the bourne shell
or awk do exactly what is needed, and scripts that rely heavily on the
POSIX interface to the OS, where I tend to use Guile scheme.
--
Barry Fishman
From: Zach Beane
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <m3y7dqm46w.fsf@unnamed.xach.com>
Barry Fishman <·············@acm.org> writes:
> I guess I don't get that enthusiastic about the kind of text compression
> produced by backticks and shell like ${name} expansions. These just
> reduce keystrokes in doing low level type operations. In a sense, they
> can be counter-productive in that they make repeated use of low level
> operations more palatable. I'm more interest in collecting higher level
> components that I can use in building utilities.
I think this is an important consideration. I was recently doing some
shell-style scripting in CL that involved CVS
checkouts. SB-EXT:RUN-PROGRAM is simple, so my first version used it a
lot to execute commands directly.
After a while, though, I needed to get more and more information via
shell command output. At that point, rather than invoking shell
commands, I found it nicer to treat a CVS module as a real object, and
to make protocol of generic functions to manipulate it. With that
change in point of view, I could work with modules in subtler ways
than just running commands. Metadata could be could be lazy-loaded and
kept in the instance. I could pass instances around, create exported
tarballs, add tags, etc.
The low-level operations were still achieved via shell commands, but
they no longer served as the main focus.
Zach
Brian Adkins <···········@gmail.com> writes:
> On Oct 25, 3:46 pm, Barry Fishman <·············@acm.org> wrote:
>> Brian Adkins <···········@gmail.com> writes:
>> > Since I'm fluent in Ruby and only learning Lisp, the former was the
>> > natural choice for me at this time, but I would think that even after
>> > I gain experience in Lisp, this sort of "quick little hack" would
>> > still be easier in Ruby, but I'd like to keep an open mind. What would
>> > this look like in Lisp?
>>
>> > def monitor_remote_file user, host, filepath, frequency=300
>> > # A string within backtick ( ` ) characters is sent to the
>> > # operating system and evaluates to the output of the cmd
>> > cmd = lambda { `ssh ·······@#{host} tail #{filepath}` }
>> > data = cmd.call
>> > while true
>> > sleep frequency
>> > if (new_data = cmd.call) != data
>> > # invoke the block that was passed to this function
>> > yield
>> > data = new_data
>> > end
>> > end
>> > end
>>
>> > require 'date'
>>
>> > monitor_remote_file('bob', '10.0.0.1', '/production.log', 600) do
>> > # code between do ... end is a "block" of code that is passed to
>> > the
>> > # monitor_remote_file function, so when the function invokes "yield"
>> > # we'll popup an X window notification
>> > `xmessage -center -title MODIFIED "File modified at
>> > #{DateTime.now}"`
>> > end
>>
>> In Clisp this is a bit longer but contains mostly reusable functions.
>
> Thanks for the example; it's a good starting point for me to explore
> this sort of thing in Lisp. When I remove comments and blank lines, I
> get 15 lines, 415 chars for mine and 30 lines, 1,212 chars for yours,
> so I'm not sure if that qualifies for "a bit longer" :) I do agree
> about the reusable functions though, and when you take that into
> consideration, it's pretty close, so I find the example encouraging.
>
> I wonder if macros can help with getting the equivalent of:
> `xmessage "file modified at #{DateTime.now}"`
>
> I realize that 'format' is quite powerful, but it would be nice to
> have something more concise at times. In particular, I find the
> following features attractive:
> 1) Evaluation of the contents of #{...} inserted into the string
> 2) Allowing different string delimiters (i.e. other than ") to
> minimize escaping
>
> I don't think either of those would be difficult in Lisp. Are you
> aware of any functions or macros that address those?
>
> The syntax of the backticks for automatically sending a command to the
> shell isn't that important to me, I'd be fine with something like:
> (shell |xmessage "file modified at #{(format_time)}"|)
>
> Would a reader macro be necessary to allow choice of string delimiters
> such as '|' above to avoid escaping \" ? It's not a big deal in this
> example, but some scenarios require much escaping.
>
This is all quite interesting, but I wanted to flag a couple of things
regarding using CL for system administration tasks (i.e. those tasks that
are often done using perl, ruby and python etc).
so far, there has been discussion and comparison made based on the amount
of code and to some extent how easily it is to do common sys admin tasks
with CL. As has been pointed out by others, you can do in CL what you can
do in these other languages. However, to really get productive with sys
admin work using CL, it will be necessary to build up a library of utility
functions that make it relatively straight-forward to do common tasks. It
is quite possible that once you had these libraries, you could be more
productive or produce more robust solutions (though often in sys admin
work, robustness is less critical as you often do scripts which will only
be used once or a couple of times). One of the main advantages of scripting
languages traditionally used for sys admin work is that there are a wealth
of modules/libraries available that have already done lots of the grunt
work. When I worked as a sys admin, I didn't have the time or resources to
develop an extensive toolbox and to be honest, didn't really need
to. Often, the starting point would be to search CPAN and find the moduels
that would make my task easier, install them and use them. A much faster
solution to coding it and debugging it myself (a luxury I just didn't have,
despite he fact coding the solution myself is personally a lot more rewarding).
As has been pointed out by others, one of the advantages of languages
like perl and Tcl is its ability to glue things together easily (i.e. take
crap from one thing, feed it into another thing and get the crap out of
that thing, manipulate it and do something else). In sys admin work, the
goal is to be able to use tools to get the job done faster. This is a
slightly different orientation to what I call programming, where you
usually have some fairly clear outcome that is likley to be used by many
people and which you hope will have some reasonable lifetime. In sys admin,
scripts are often 'dirty' and somewhat hackish, will probably only ever be
used by the author or a few specific users and are usually a lot more
straight forward or simple in design. In programming or writing
applications, things are usually more complex, are often developed by teams
of programmers, and because of efficiency and maintenance issues, involve
development of and refinement of algorithms, considerable 'deep thought'
about the problem and often involves extended consultation with various
stakeholders. Sys admin scripting is often just what you do to make your
task easier. Often, you will have a new task to do and you will just sit
down, knock up a basic script and automate the process. Over time, you may
extend and refine the script if it is used regularly, but often, you will
never run it again or you will significantly modify it to deal with a
similar problem in the future.
I think there are a few issues which need to be considered before deciding
to use CL for your sys admin tasks. These include -
- Do you have the time and can you justify using that time to develop CL
libraries to do what is already available in other scripting languages?
Will you have the time to maintain these and keep up to date with changes
in things like OS utilities, kernel service changes, protocol changes,
etc.
- Are you the only sys admin? These days, only trivial small sites can
survive with a single sys admin. Much of what you do needs to be done in
a way that your colleagues can also maintain, fix and extend what you
have done.
- Is CL the best lisp to do this in? There are a number of other languages
in the lisp family which have a more sys admin orientation. These include
- lush - The Lisp User Shell
- schsh - The Scheme user shell
- Guile - A scheme based scripting language oriented towards sys
admin/scripting.
- Rep - a lisp/scheme style language that has good OS integration
Personally, I find all languages have their relative pros and cons. For
example, Tcl is one of the easiest languages I've used where I want to add
functionality from some other library that is written in another language,
such as C or C++. Perl is very useful for processing log files and other
bits of text, especially with regexp requirements. I've found ruby useful
when I want a more structured OO solution, but not when regexp and large
data sets are involved (Ruby's regexp is much slower than Perl), but I find
Ruby easier to maintain than perl, which can be a nightmare (especially if
different people have written different bits). CL I find really useful for
larger, more complex 'application' type solutions, especially if I want to
'play' with the problem and get to understand it better. It is very useful
as a prototyping language or for generating data to be input into another
process (i.e. generating database definitions for multiple different
databases from the same CL based definition).
As a sys admin, I think the goal is to know what tools are available and
which ones to apply to which task or at what times. Its not about using
your favorite language to do everything. Sys admin is not about
programming, its about configuration and maintenance. Scripting is just the
tool you use to become more efficient and obtain higher consistency in
results. Its also about getting results that can be maintained by others
and not about creating some wonderful new management layer which only you
understand. A good sys admin should be able to go on holidays and not be
missed by either their colleagues or users/clients/stakeholders and there
shouldn't be any observable drop in service.
Tim
--
tcross (at) rapttech dot com dot au
I'm going to give you the Erik Naggum response[1]:
Dirty and "hackish" scripts are reflections of the system being
administrated. They reflect how dirty and "hackish" the underlying
system is and a properly designed system such as Genera would not
require glue code that manipulates text.
Text processing is for the weak and not everything is text. Instead of
having the operating system allow an easy way of passing objects
between different programs, you must use shell scripts and Perl to
dump string representations to the receiving programs and those
receivers must then parse it all out and re-create objects that
already existed in the other program.
Regular expressions are fine and dandy when dealing with the horribly
broken and inconsistent syntax of configuration scripts. But again,
you are not fixing the problem, you are merely patching over it and
allowing this tragedy to continue. Why must data be separated from the
language? Write your configuration scripts in Lisp syntax and you get
the parser for free, just keep (read)ing the file and processing those
lists.
[1] can lisp do what perl does easily? --
http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863
From: Zach Beane
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <m3myu4me6b.fsf@unnamed.xach.com>
OMouse <······@gmail.com> writes:
> I'm going to give you the Erik Naggum response[1]:
OMouse, I served with Erik Naggum. I knew Erik Naggum. Erik Naggum
was a friend of mine. OMouse, *you're* *no* *Erik* *Naggum*.
Zach
On Oct 27, 5:38 pm, Zach Beane <····@xach.com> wrote:
> OMouse <······@gmail.com> writes:
> > I'm going to give you the Erik Naggum response[1]:
>
> OMouse, I served with Erik Naggum. I knew Erik Naggum. Erik Naggum
> was a friend of mine. OMouse, *you're* *no* *Erik* *Naggum*.
>
> Zach
It was meant as a joke, sorry. This is why I linked to his post at the
bottom and I enjoyed his writing on the subject. I didn't think that I
was implying that I'm anything like him. Definitely not. No disrespect
was intended.
Sincerely sorry for offending anyone here,
Rudolf Olah
On Oct 27, 9:29 pm, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> On Sat, 27 Oct 2007 16:25:52 -0700, OMouse wrote:
> > On Oct 27, 5:38 pm, Zach Beane <····@xach.com> wrote:
> >> OMouse <······@gmail.com> writes:
> >> > I'm going to give you the Erik Naggum response[1]:
>
> >> OMouse, I served with Erik Naggum. I knew Erik Naggum. Erik Naggum
> >> was a friend of mine. OMouse, *you're* *no* *Erik* *Naggum*.
>
> >> Zach
> > It was meant as a joke, sorry. This is why I linked to his post at the
> > bottom and I enjoyed his writing on the subject. I didn't think that I
> > was implying that I'm anything like him. Definitely not. No disrespect
> > was intended.
>
> http://en.wikipedia.org/wiki/Senator,_you_are_no_Jack_Kennedy
>
> --
> I'm sure the above forms some sort of argument in this debate, but I'm not
> sure whether it's for or against.
> -- Boris Schaefer
> (setq reply-to
> (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
I have shown my young age. That one flew over my head and damnit, I'll
find a way to get you back Zach! ;P
Rudolfo lah
From: Frank Goenninger DG1SBG
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <lzejfgcj1d.fsf@de.goenninger.net>
Zach Beane <····@xach.com> writes:
> OMouse <······@gmail.com> writes:
>
>> I'm going to give you the Erik Naggum response[1]:
>
> OMouse, I served with Erik Naggum. I knew Erik Naggum.
You *knew* ? I assume he's still alive ... Or not? Really worrying ...
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
My mind does not seem to start working until after I post.
Barry Fishman <·············@acm.org> writes:
> (defun equal-lines-p (alines blines)
> "True if lists of lines match"
> (and (= (length alines) (length blines))
> (every #'string= alines blines)))
Of course just calling EQUAL works as well. :-(
And "tail" seems a bit of overkill. Shouldn't "wc -l" work just fine,
unless you want the new lines to appear in the xmessage, which I don't
think the ruby script is doing.
--
Barry Fishman
On Oct 25, 4:47 pm, Barry Fishman <·············@acm.org> wrote:
> My mind does not seem to start working until after I post.
>
> Barry Fishman <·············@acm.org> writes:
> > (defun equal-lines-p (alines blines)
> > "True if lists of lines match"
> > (and (= (length alines) (length blines))
> > (every #'string= alines blines)))
>
> Of course just calling EQUAL works as well. :-(
>
> And "tail" seems a bit of overkill. Shouldn't "wc -l" work just fine,
> unless you want the new lines to appear in the xmessage, which I don't
> think the ruby script is doing.
Yes, in this example, checking the line count, modification date, etc.
would be fine. I was probably going to make use of the tail data
originally. I expect the overhead of the ssh call is more costly than
tail though.
From: Kamen TOMOV
Subject: Re: my experience learning perl and common lisp so far
Date:
Message-ID: <uabq6686p.fsf@cybuild.com>
On Thu, Oct 25 2007, Brian Adkins wrote:
> I don't recall someone asserting that Lisp is better suited for
> sysadmin scripts than Perl or Ruby before, so I have to admit I'm
> curious.
Lisp is well suited for a wide range of applications. In fact because
I have plenty of bad experience with other languages I can extend my
assertion beyond what I said - Lisp is better suited than Perl, Ruby,
Java, PHP, Python, etc. for whatever these languages are suitable
for. Also IMO many C++ applications would have been better if Lisp was
used instead. With "better" I mean stability, maintainability,
extensibility, etc.
Of course it is hard to compete in terms of tools with languages like
Java. It's also hard to compete in terms of popularity with
Algol-derived languages because this is what kids study these
days. But the big players order the music and apparently they have an
awful taste for it. Still my fellow colleagues complain that one of
the the most popular Java IDE, Eclipse, crashes several times a day
with no particular reason while this does not happen with Slime (at
least not to me) or it happens rarely.
So lets review what's special about system administration so that we
can identify possible issues with the tool we use... It is an area
where we need close interactions with the operating system - generally
we need to know how to do:
1. Process management - exec, kill, IPC, etc.;
2. Device management - CPU, HDD, Memory,...;
3. File management;
3. Networking;
While I'd agree that some of these areas are not standardized in CL,
I'd argue that there are good enough Lisp tools for each purpose in
the list.
> Would you be willing to share a small Lisp script or two that you've
> used for sysadmin types of tasks?
That piece of code is from my first real Lisp application that I wrote
in 2005. The app was tiny and I used it for backups on my CMUCL based
system.
(defun tar ()
(let ((last-full-backup (backup-file-name "last-month")))
(multiple-value-bind
(filename opt_newer)
(if (or (= (get-day-of-month) +monthly-backup-day+) (not (probe-file last-full-backup)))
(values "last-month" (get-oldest-date))
(if (equal (get-day-of-week) +weekly-backup-day+)
(values +weekly-backup-day+ last-full-backup)
(values (get-day-of-week)
(format nil "~D" (get-day-month-yesterday)))))
(run-program
+tar+
`("-cf"
,(backup-file-name filename)
"--newer"
,opt_newer
"--preserve-permissions"
"--same-owner"
"--verify"
"--totals"
"-P"
,@(get-dir-list))
:output nil :error nil))))
(process-exit-code (tar))
> For example, here's a little script to monitor a file on a remote
> system for changes by periodically executing a remote command via
> ssh and comparing the data received and popping up an X window
> dialog when a change is detected.
>
> Since I'm fluent in Ruby and only learning Lisp, the former was the
> natural choice for me at this time, but I would think that even
> after I gain experience in Lisp, this sort of "quick little hack"
> would still be easier in Ruby, but I'd like to keep an open
> mind. What would this look like in Lisp?
Quick little hacks are great, but we often have so many problems with
them that a slow, solid solution would suit us better. Think about
special characters in strings or internationalization. So if a task is
big enough that it can't be done easily with a few shell commands,
than we need a general purpose programming language and Lisp suits me
best.
Regards,
--
�����
On Oct 25, 10:15 am, Kamen TOMOV <·····@cybuild.com> wrote:
> Are you trying to say that there is a better tool than Lisp in c.l.l.?
> There's no better programming language as far as we know so you better
> have a *good* reasoning 'cause otherwise it would be laaame
> assertion.
>
> If you had said that Lisp is not such a good idea because of the
> people factor (co-workers and/or management) that might have been
> fine, but you are not saying that. You are saying that Perl and
> Ruby (?!) is a better tool for system administration.
>
> --
> �����
Nooo, i'm just kidding