[Info-vax] Long uptime cut short by Hurricane Sandy

[Jan-Erik Soderholm]

> In article <an0jjrFduj7U1 at mid.individual.net>, billg999 at cs.uofs.edu (Bill Gunshannon) writes:
>> In article <00ACE364.926A71CC at sendspamhere.org>,
>> 	VAXman-  @SendSpamHere.ORG writes:
>>> In article <keerfn$i53$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>>>> VAXman- @SendSpamHere.ORG wrote:
>>>>
>>>>> In DCL, one can delete a character from a string with - (subtract) and one
>>>>> can add strings with a "+" (just like in Hoff's bash example!).  I can, for
>>>>> example, remove the "$" in this string: "This is a $ sign." with -"$".  In
>>>>> DCL, the subtract character will delete the very first occurrance of said
>>>>> character that's specified when encountered in the string.  If no character
>>>>> is found, nothing is done.  HB pointed out that using the ()s would define
>>>>> the scope better but I assumed no "funny" characters would be in the file
>>>>> prefix.  The multiple -"-" -"-" remove the dashes in the time and the -":"
>>>>> -":" remove the colons in the time.  Surely, you could see that if you'd
>>>>> have tried to understand it instead of choosing to denigrate DCL.
>>>>
>>>> Yep, that's where I've used it.  When you got procedures that run often
>>>> and you need files with a date and time stamp in the filename it's very
>>>> useful.  But if you don't use it often, it does (at least for me) stop
>>>> you when you're skimming through DCL code.  Even if you're aware of what
>>>> it does, I still have to stop and think about it.
>>>>
>>>>> A lack of understanding of the semantics doesn't make it cryptic.
>>>>
>>>> Actually, for me it does, but, if it was preceded by something such as:
>>>>
>>>> $! Build a filename with date stamp without the dashes and colens
>>>
>>> Certainly... and an unnecessary I/O too!
>>>
>>>
>>>> Then the DCL code would be much easier to follow ....
>>>>
>>>> My DCL code has lots of comments, but to be fair (I hate doing that) the
>>>> bash code would  benefit from comments also.
>>>
>>> I've seen more comments in DCL procedures than I've seen in bash scripts!
>>
>> Is that the scripting tools fault?
>

That it should be anyones fault implies that it is a problem.
Better programmers simply write more comments.