Mombu the Programming Forum sponsored links

Go Back   Mombu the Programming Forum > Programming > 4NT anomaly in piping
User Name
Password
REGISTER NOW! Mark Forums Read

sponsored links


Reply
 
1 24th May 03:35
stan brown
External User
 
Posts: 1
Default 4NT anomaly in piping



Since buying 4NT on 30 January, I've noticed something very strange
with piping that has me completely baffled. Can someone help me
figure out if this is indeed a 4NT bug?

Here's a small illustration that's repeatable.

A file f:zonk contains my 4NT aliases, and I want to find those
that begin with the letter d. In the CMD.EXE command prompt, I type
type f:zonk|grep32 /zq ^^d
and everything goes fine: I get my output of 10 aliases. But when I
type the same command in 4NT, the grep32 program reports that it
found zero matches.

I'm pretty sure this is a piping problem because when I change the
command to redirect standard input
grep32 /zq ^^d <f:zonk
then grep32 finds the 10 aliases under CMD.EXE or under 4NT.


--

Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
  Reply With Quote


  sponsored links


2 24th May 03:35
steve fábián
External User
 
Posts: 1
Default 4NT anomaly in piping



What character do you use as command separator, escape, and parameter? 4NT
defaults are different from 4DOS.
What version of 4NT?
--
Steve
  Reply With Quote
3 24th May 03:35
stan brown
External User
 
Posts: 1
Default 4NT anomaly in piping


Sorry, I meant to include that relevant information but somehow
completely forgot. Separator &, escape ^, parameter $. VER says
"4NT 6.01.239U Windows XP 5.1".

Again, note that redirecting input with < works on both, but piping
works on CMD.EXE and fails on 4NT. (It's gotta be more complicated
than that, because some other piping exercises hve succeeded on 4NT
for me.)

--

Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
  Reply With Quote
4 24th May 03:35
steve fábián
External User
 
Posts: 1
Default 4NT anomaly in piping


Note the great change of behavior of piping from 4DOS to 4NT. Since 4DOS
operates in a single program environment, piping is emulated by using a
temporary file. 4NT operates in a multiprogrammed environment, and piping is
between concurrent 4NT sessions. The session on the right side of a pipe may
be started before execution of the command on the left side, and it executes
4START.BTM before executing the command itself (if there is one). Two
unrelated possibilities (among many others) of why this would result in your
observations:

1) The 4START.BTM executed before grep32 interferes with grep32

2) Your grep32 starts before there is anything in the pipe, and immediately
shuts down

Regardless of the piping issue, I wonder what grep version you use. All
versions I've ever used search files directly, so you don't need to deliver
the data through redirection or piping. For each version on my system the
command

grep "^d" f:zone

(with additional options if you want linenumbers, etc.) would work. Even
using a wildcard for file specification works.
--
Steve
  Reply With Quote
5 24th May 03:35
charles dye
External User
 
Posts: 1
Default 4NT anomaly in piping


Can you post a link to this particular grep32? It might help
someone to replicate your issue.

--
Charles Dye raster@highfiber.com
  Reply With Quote
6 24th May 03:35
stan brown
External User
 
Posts: 1
Default 4NT anomaly in piping


Thanks to both Steve and Charles for responding. I've consolidated
my responses below.

Fair enough. I've packaged the executable, the data file, and an
illustrative batch file as
http://oakroadsystems.com/nonce/pipeprob.zip (77K)
Try it under 4NT by typing
problem
Try it under XP by typing
cmd /c problem

"Steve Fábián" wrote in comp.os.msdos.4dos:

I understand this is different from 4DOS, but is it also different
from XP's CMD.EXE? The description in the Win XP help is sketchy,
but it doesn't say anything about concurrent processes, just that
output of the first command becomes input to the second command.


Here's my 4START.BTM:

iff %_shell == 0 then
cls
prompt $P$g$s
else
prompt $P(%_shell)$g$s
endiff
setdos /a1
iff %@index[%path,%UU] == -1 then
path %UU;%path
endiff
set ZIPOPT=-o -D -T -b %TEMP%

I rather suspect this is what's happening. The great question then
is, what to do about it?


And the same is true with my GREP. You understand that this is a
pared-down example in an attempt to eliminate some extraneous
variables. The original was
alias | grep32 ^^d
because I wanted to list the aliases that began with d.

I very frequently want to filter a command's output in this manner.
I hope it's not going to be unreliable in 4NT -- that would be a
problem for me since it seems to work in XP's CMD in all my tests
so far.

--

Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
  Reply With Quote
7 24th May 03:35
steve fábián
External User
 
Posts: 1
Default 4NT anomaly in piping


I'll try it later.


The ******** difference is the use of the session start program (by default,
4STARt.BTM). There is a little more in 4NT's help, esp. the warnings about
4START, in topics autobatch and piping (on the bottom of the help pane is
the name of the topic). You can get to each topic with the command "help
specifictopic", e.g., help piping. However, there is nothing about the
relative timings, esp. no comparison of the order in which CMD and 4NT do
all the little things needed, e.g., create the pipe, create the secondary
shell, execute the command in the primary shell feeding the pipe, execute
the command in the secondary shell consuming the pipe, close the secondary
shell when command execution is completed after executing 4EXIT.BTM (if
any).

Please read in the AUTOBATCH topic the section about pipes and the use of
the _PIPE internal variable to bypass parts or all of 4START.BTM.


There is nothing obvious here to interfere with grep32.


If it is not grep itself, or if you need 4NT to deal with the problem,
you'll need to communicate with JPsoft in jpsoft_support@email.sparklist.com
or send email to support@jpsoft.com. I am on contract with JPsoft for help
file maintenance, but not for general technical support. Like Charles Dye, I
monitor this venue out of personal interest.


You could just use "alias d*" to do that!


I had problems with redirection of 16-bit text ("console") applications
under Win98, but not with piping, and neither redirection nor piping
problems with WinXP and 4NT 6.01. Of course, I found awk too awkward to use,
and sed to be to sad... I just use the string functions of 4NT, or my own
user defined functions (many of which Rex implemented at my suggestions) and
batch programs. They are slower than a compiled program, but a lot faster to
develop and test. The only major problem is the presence of special
characters in the data to be ****yzed, esp. []()<|>'"`&^ which have
syntactic meaning in 4NT, but not in filter programs.
--
Steve
  Reply With Quote
8 24th May 03:35
r.a.g. seely
External User
 
Posts: 1
Default 4NT anomaly in piping


FWIW, here is what I get under 4NT (I used my own file, and grep'd two ways,
once directly, once with a pipe). The only difference is that directly you
get the filename listed, with the pipe you don't. (I got the same output
with CMD, by the way.) So, I suspect the problem is the ^d part of your
command. I do get the "error" you describe when running "problem.bat" under
4NT, not under CMD. And if I alter the commands below, replacing "strong" with
"^strong", I get the same error you get there too. I don't think this is a pipe
problem in the usual way. ==============

grep32 7.911 Copyright 1986-2005 Oak Road Systems http://oakroadsystems.com

grep: This is the unregistered evaluation version.
To register and get more features (and suppress this message)
see file REGISTER.TXT or visit http://oakroadsystems.com/sharware/


---------- hellodolly.txt
You're still goin' strong
grep: found 1 match in 1 file of 1 examined

Thanks for trying grep. Your feedback is very welcome! If you like grep, please
buy it at http://oakroadsystems.com/sharware/ -- if it doesn't meet your needs,
please write to support@oakroadsystems.com and tell us how we can improve it.

grep32 7.911 Copyright 1986-2005 Oak Road Systems http://oakroadsystems.com

grep: This is the unregistered evaluation version.
To register and get more features (and suppress this message)
see file REGISTER.TXT or visit http://oakroadsystems.com/sharware/

You're still goin' strong^M
grep: found 1 match in 1 file of 1 examined

Thanks for trying grep. Your feedback is very welcome! If you like grep, please
buy it at http://oakroadsystems.com/sharware/ -- if it doesn't meet your needs,
please write to support@oakroadsystems.com and tell us how we can improve it.


-- -= rags =-
<rags AT math . mcgill . ca>
<http://www.math.mcgill.ca/rags>

Eliminate Spam with Mailwasher Pro
<http://entier.ecosm.com/link/?webepq>
  Reply With Quote
9 24th May 03:35
charles dye
External User
 
Posts: 1
Default 4NT anomaly in piping


My take is that this is not a problem with the pipe per se, but a
difference between the way 4NT and CMD parse the right-hand
side of the pipe. I suggest that you simply enclose the troublesome
regexp in double quotes, rather than escaping escapes. This
approach ought to work in both 4NT and Brand X:

type zonk | grep32 "^d"

alias | grep32 "^d"

In 4NT you may also be able to get away with e.g.

alias | grep32 ^d

but this almost certainly won't work in CMD. Bug or feature?
Theological question; ask Rex....

--
Charles Dye raster@highfiber.com
  Reply With Quote
10 24th May 03:35
stan brown
External User
 
Posts: 1
Default 4NT anomaly in piping


Good ****ysis! They did indeed work.

It feels like a bug to me, that something works in CMD but not in
4NT. If 4NT parses the part after the pipe so that the command
doesn't receive any input, that seems wrong IMHO.

I'm nearing the end of my 30-day money-back period, and trying to
evaluate whether to keep 4NT. I'd miss functions, but the other
features I use -- principally command grouping and filename
completion and iff...endiff -- are now implemented in CMD.

--

Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
  Reply With Quote
Reply


Thread Tools
Display Modes




Copyright © 2006 SmartyDevil.com - Dies Mies Jeschet Boenedoesef Douvema Enitemaus -
666