SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Tue, 17 Nov 1998 04:02:12 PDT
From:	dallasii@kincyb.com
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Queues2etc.

SL>
SL> Date: Mon, 16 Nov 1998 08:13:10 PDT
SL> Reply-To: scoug-programming@scoug.com
SL> From: Steven Levine
SL> To: scoug-programming@scoug.com
SL> Subject: SCOUG-Programming: More\1b[1;33m2QUEUE\1b[1;33m2,\1b[1;33m2Full\
1b[1;33
SL>
SL> In , on 11/16/98
SL> at 05:10 AM, dallasii@kincyb.com said:
SL>
SL> >SL> Qnew has a space "prepended" because you have 2 spaces before 'Qnew'.
SL> >The SL> first is discarded. The 2nd becomes part of the argument passed
SL> >to test8. SL> Not what you expected, but that's the way it works. You'll
SL> >notice I tend SL> to be fussy about spaces in my code. There's a reason.
SL>
SL> I also forget to mention that the parse work differently for last argument
SL> or in your case the only argument.
SL>
SL> parse a b
SL>
SL> will strip spaces before setting a, but will strip nothing before setting
SL> b.

Ah!

SL>
SL> >Also, START doesn't seem to like pipes for whatever reasons -
SL> >DETACH seems to handle them more reliably from this environment. On one
SL>
SL> I'd suspect timing again. Recall that queued() only says there are no
SL> lines now, not that more will never appear. You need a better way to know
SL> that you have reached the end of input.

I grant that being more complex and capable, START probably takes
longer to fire up than DETACH, (even though both are internal to CMD.EXE)
but the queues are already loaded
with everything that they are going to hold before the pipe is started -
launching the pipe first, and reading the queue as data shows up is
a future project, and will definitly need some changes to the queue->pipe
utility - no argument there.

I guess vaguely in the back of my mind is the idea of stuffing the data into
various queues, then launching a set of pipelines for each queue,
the pipelines (plural) running in background at the same time.

SL>
SL> >of the exploritory kludges, LineOut seemed to choke outputing a '|'
SL> >character.
SL>
SL> Unlikely.

Your right about that, I just re-ran the case with the
D2C(124) replacing '|', but with '|', and the .CMD file generated was OK,
the problem was elsewhere.

SL>
SL> > ....sort of but didn't go into background in Korn shell - hung in
SL>
SL> KSH is my preferrred shell under Unix and have I have the OS/2 version,
SL> but have never had the time to install it. The CMD and KSH delimiters and
SL> escape logic are so different, I could easily set confusion setting in.
SL> Were you just testing KSH does it do something special you need?

I've been using it for a couple of weeks.
Misc. reasons.

SL>
SL> The KSH/2 I have is a bit old and AFAIK, is no longer maintained. It's
SL> possible you are just running up against defects.

Probably just an unavoidable compromise.
When I was reading over the documentation for the port of pdksh,
I was pleasantly shocked that it even recognized and tried to
handle appropriately .CMD files.
I need to shutdown and restart with different values for
OS2_SHELL and COMSPEC, and see what happens.

I just completed some more experiments.
Results:
COMSPEC=c:\os2\cmd.exe test7
works, but detach versions put the pipe into background, (as desired)
start versions hang in foregroud till completion, and then resume
execution. (not really desired)

launching pipes into backgound execution from original .CMD interpreter
is getting pretty convoluted.

SL>
SL> Steven
SL>
SL> --
SL> -----------------------------------------------------------
SL> Steven Levine MR2/ICE #10183
SL> -----------------------------------------------------------
SL>
SL>
SL>
SL>
SL>
PS>
PS> Date: Mon, 16 Nov 1998 11:48:40 PDT
PS> Reply-To: scoug-programming@scoug.com
PS> From: Peter Skye
PS> To: scoug-programming@scoug.com
PS> Subject: SCOUG-Programming: More\1b[1;33m2QUEUE\1b[1;33m2,\1b[1;33m2Full\
1b[1;33
PS>
PS> dallasii@kincyb.com wrote:
PS> >
PS> > I ran into some other problems due to using PD Korn Shell as my
PS> > commandline - first really tricky problem it's given me.

I just remembered
one other major mismatch that I've encountered so far is accessing the
OS/2 FIND command - it seems to be an almost perfect syntax
clash. So far my kludge to use it renders it almost unrecognizable.

PS> > As best I can figure, there were so many environment variables pointed
PS> > at so many different shells, that some where along the way for the
PS> > attempted pipe the shell got swapped and the fact that there was
PS> > a pipe being processed seemed to get dropped.
PS> > Also, START doesn't seem to like pipes for whatever reasons -
PS> > DETACH seems to handle them more reliably from this environment.
PS> > On one of the exploritory kludges, LineOut seemed to choke outputing
PS> > a '|' character.
PS>
PS> -and-
PS>
PS> Steven Levine wrote:
PS> >
PS> > KSH is my preferrred shell under Unix and have I have the OS/2 version,
PS> > but have never had the time to install it. The CMD and KSH delimiters an
d
PS> > escape logic are so different, I could easily set confusion setting in.
PS> > Were you just testing KSH does it do something special you need?
PS>
PS> I'd _really_ like the two of you to discuss alternate OS/2 shells at a
PS> Programming SIG meeting. I've written alternate shells but not for
PS> OS/2, and I'd like to know what's available and why and when you might
PS> want to change.
PS>
PS> If you're willing to do so, maybe we can get Rollin to give up a few
PS> minutes of his FTP Server time. :)
PS>
PS> - Peter Skye
PS>
PS>
PS>
PS>
PS>
PS>
PS>
PS>
PS> Date: Mon, 16 Nov 1998 11:48:33 PDT
PS> Reply-To: scoug-programming@scoug.com
PS> From: Peter Skye
PS> To: scoug-programming@scoug.com
PS> Subject: SCOUG-Programming: Stem\1b[1;33m2variables\1b[0m
PS>
PS> dallasii@kincyb.com wrote:
PS> >
PS> > Here's a somewhat bloated attempt at solving Mr. Skye's
PS> > question about stem variables subjected for ridicule! :-)
PS> > (Hey, we're supposed to be discussing queues here.)
PS>
PS> Hiya Dallas,
PS>
PS> I shoulda guessed you'd figure out a way to sneak queues into a
PS> solution. :)
PS>
PS> Let's see, you're taking the stem variable's contents and stuffing them
PS> into a queue, then calling the subroutine where the contents are pulled
PS> back out of the queue for processing. When done, you stuff the contents
PS> back into the queue, return to the calling routine, and let the calling
PS> routine pull the results back into the original stem variable.

You got it. Just emulates what goes on behind the scene in C or PASCAL,
where they use the hardware stack to pass struct's and such to routines.
By the way, I meant my solution was to be subjected to ridicule,
not your question. I welcome criticism to the idea. Personally,
I'm not convinced it's worth the effort, but maybe a look.
(Basicly, I think this approach would go better in a real
OOP environment, but the basic idea isn't really restricted to
OOP env., just all the ugly details are out in the open.)

On further reflection (a muffin at a local doughnut shop),
maybe it would be better to replace the
stem variable with a queue altogether - download it in the
procedures to a stem variable for messy operations on individual
elements, then requeue them -
do you really need to have random access to the elements
most of the time? Maybe do away with my 'Global stack' idea,
and have the the subroutines operate on some dedicated queues whose
names are passed to them.
All the PUSHA, POPA stuff might just be adding unneeded DO loops.

PS>
PS> All this because REXX doesn't allow you to pass a stem variable to a
PS> procedure.
PS>
PS> I hate REXX.

I like it, but not handling stem variables with procedures smoothly
is definitly a weak spot.
Maybe part of the problem is that SAA ReXX was first started out
as a *scripting language* to glue programs and data together,
but had so much capability people
started using it for implimenting algorithms and their libraries and such,
more than what was originally intended (<- speculation).

PS>
PS> You get an A+ for your solution, and another A+ for ingenuity. Can we
PS> get you to discuss this at next Saturday's Programming SIG? I'm getting
PS> tired of the FTP project.

I really should be studying the FTP thing, but I'm willing
to talk on anything desired. The shell stuff borders on some stuff
I was going to write up for Carla, but with a slightly
different emphasis.
Actually I've been learning a lot from all this.

PS>
PS> - Peter
PS>
PS>
PS>
PS>
PS>
PS>
PS>

Regards,
Dallas E. Legan II
(562) 862 - 4854 ext. '*'

L
E
G
A
N
@
A
C
M
.
O
R
G

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 17 | November | 1998 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.