J: winexec problem? 
Author Message
 J: winexec problem?

I'm trying to use winexec in J (as in wd 'winexec "write.exe myfile.txt"'),
but I'm having problems.  

I can do

wd 'winexec write'
wd 'winexec "write.exe myfile.txt"'
wd 'winexec calc'
wd 'winexec notepad'

but I can't do

wd 'winexec excel'
wd 'winexec acroread'  NB. Adobe Acrobat Reader
wd 'winexec winword'

However, I can do

wd 'winexec "d:\web\acroread\acroread i:\myfile.pdf"'

for example.

Is there a reason that some programs don't need fully qualified pathnames
and some do?  I'm running on NT3.51 and J 3.04a.

Thanks,

Bill

--
Bill Harris                             Hewlett-Packard Co.
R&D Engineering Processes               Lake Stevens Division

phone: (425) 335-2200                   8600 Soper Hill Road
fax: (425) 335-2828                     Everett, WA 98205-1298



Sun, 26 Dec 1999 03:00:00 GMT  
 J: winexec problem?



Quote:
> I'm trying to use winexec in J (as in wd 'winexec "write.exe
myfile.txt"'),
> but I'm having problems.  

> I can do

> wd 'winexec write'
> wd 'winexec "write.exe myfile.txt"'
> wd 'winexec calc'
> wd 'winexec notepad'

> but I can't do

> wd 'winexec excel'
> wd 'winexec acroread'  NB. Adobe Acrobat Reader
> wd 'winexec winword'

> However, I can do

> wd 'winexec "d:\web\acroread\acroread i:\myfile.pdf"'

> for example.

> Is there a reason that some programs don't need fully qualified pathnames
> and some do?  I'm running on NT3.51 and J 3.04a.

I can give half an answer to this. wd 'winexec write' works because write
is on Windows' search path, and wd 'winexec excel' fails because excel is
not on Windows' search path. There is nothing special about write, excel,
or winexec here. I dont know what makes some paths visible to Windows and
not others, but notice that your examples that work have executables in the
windows subdirectory.


Wed, 29 Dec 1999 03:00:00 GMT  
 J: winexec problem?


Quote:


>>> I'm trying to use winexec in J (as in wd 'winexec "write.exe
>>myfile.txt"'),
>>> but I'm having problems.

....
....

Quote:
> I can give half an answer to this. wd 'winexec write' works because write
> is on Windows' search path, and wd 'winexec excel' fails because excel is
> not on Windows' search path. There is nothing special about write, excel,
> or winexec here. I dont know what makes some paths visible to Windows and
> not others, but notice that your examples that work have executables in the
> windows subdirectory.

On a related subject then I used to create bat files and execute them when
I needed to do stuff I could not manage in J. I do it in C++ now and combine
it with J. But that is another story.

Following is an example on how to get the environment vars in J using winexec:

require 'misc'

getenv=: 3 : 0
'set' fwrites 'getenv.bat'
 wd ' winexec  "getenv.bat > getenv.txt"  sw_showminimized;'
6!:3[1
 fread 'getenv.txt'
)

systemroot=: 3 : 0
a=.getenv''
b=. chop a
NB.c=.,>(>(<'SystemRoot')  -: each 10{. each b)#b
c=.,>(>(<'windir')  -: each 6{. each b)#b
NB.11}.c
7}.c
)

   systemroot''
   getenv''

Well for all its worth than use the above more as an example
of how to use batfiles from J because there is a better way of
getting the environment vars in J now.

   2!:5 'windir'

   systemroot''
D:\WINNT

   2!:5 'windir'
D:\WINNT
   a=.   systemroot''
   b=.   2!:5 'windir'

notice that a and b are not the same
   a -: b
0
to inspect it use av from convert
   require'convert'
   av a
68 58 92 87 73 78 78 84 13
   av b
68 58 92 87 73 78 78 84

a=CR
0 0 0 0 0 0 0 0 1

So you see an extra CR at the end of the
line you get from the batfile read.

You can remove that easily with:

   (-.   a=CR)
1 1 1 1 1 1 1 1 0
   (-.   a=CR)#a
D:\WINNT
   c=.(-.   a=CR)#a
   b-:c
1

Now b and c are the same.

Thus ends this little Sunday morning lesson
/Gosi



Thu, 30 Dec 1999 03:00:00 GMT  
 J: winexec problem?


..

Quote:
>So you see an extra CR at the end of the
>line you get from the batfile read.

>You can remove that easily with:

For the code below, note that the dyadic form of -.
removes elements matching the right argument from
the left argument, thus:

   b -: a -. CR
1

Quote:
>   (-.   a=CR)
>1 1 1 1 1 1 1 1 0
>   (-.   a=CR)#a
>D:\WINNT
>   c=.(-.   a=CR)#a

which also can be written, if you prefer the reduction:

    c=. ( a ~: CR) # a

Quote:
>   b-:c
>1

>Now b and c are the same.

>Thus ends this little Sunday morning lesson
>/Gosi

--
|\/| Randy A MacDonald       | If the string is too tight, it will snap

     BSc(Math) UNBF '83      | APL: If you can say it, it's done.

     I use Real J            | Also http://www.godin.on.ca/randy/
------------------------------------------------<-NTP>----{ gnat }-


Thu, 30 Dec 1999 03:00:00 GMT  
 J: winexec problem?



: > I can give half an answer to this. wd 'winexec write' works because write
: > is on Windows' search path, and wd 'winexec excel' fails because excel is
: > not on Windows' search path. There is nothing special about write, excel,

Yes, after I posted the question, I realized that was the likely answer.
Looking at my PATH variable pretty much confirmed that.

I'm used to a Unix PATH variable that pretty much includes everything, so
dealing with a severely truncated PATH under Windows feels different.  I
recognize that NT can deal with longer PATH contents, but that means some
configuration work on my part each time I install my application.  I was
hoping someone had experience querying the registry under J to find those
applications automatically.

: of how to use batfiles from J because there is a better way of
: getting the environment vars in J now.

:    2!:5 'windir'

That's pretty nifty, even though it doesn't do what I need done.  However,
when I look through the help text or release notes for my copy of J (J 3.04
A), I don't find anything in the 2!: series except 2!:0, 2!:1, and 2!:55,
and the first two don't work under Windows (2!:55'' provides a really quick
bail-out from J with no exit prompting, I just discovered).  

So, is my copy of J out of date?  Where is 2!:5 (and any other such new
foreigns, such as querying the registry --- well, I can always hint, can't
I?) documented?

Thanks,

Bill

--
Bill Harris                             Hewlett-Packard Co.
R&D Engineering Processes               Lake Stevens Division

phone: (425) 335-2200                   8600 Soper Hill Road
fax: (425) 335-2828                     Everett, WA 98205-1298



Sat, 01 Jan 2000 03:00:00 GMT  
 J: winexec problem?

Quote:

> ...
> I'm used to a Unix PATH variable that pretty much includes everything, so
> dealing with a severely truncated PATH under Windows feels different.  I
> recognize that NT can deal with longer PATH contents, but that means some
> configuration work on my part each time I install my application.  I was
> hoping someone had experience querying the registry under J to find those
> applications automatically.
> ...

The length of the PATH variable is not the only area where UNIXes show
their superiority over Mickeysoft OSses :-)

But seriously, I do not believe that you should have everything possible
in your PATH (in any OS). While this may seem convenient, it becomes the
sysadmin's nightmare, especially when you are asked to support multiple
versions of the same software (C compilers is a common case). Other
variables may also be affected (commonly in UNIX, LD_LIBRARY_PATH). Far
better is to have a short path which includes a directory of shell
scripts or batch files which set your environment variables, run the
executable, and readjust or remove the environment variables in OSses
where subshelling is not supported.

As an example, you may have "c:\batfiles" in your path and the file
c:\batfiles\excel.bat may contain something like:

        rem     Run EXCEL
        rem     Set required paths:
        set OLDPATH=%PATH%
        set PATH=c:\dir1\dir2\mickeyslush\excel;%OLDPATH%
        rem     Run the program
        excel.exe
        rem     Done! Now return to original state:
        set PATH=%OLDPATH%
        set OLDPATH=

Now I suspect that your winexec cmd from J might just work. I'd be
interested to know for sure.

This works a lot better in UNIX, where each instance of the shell may
have a different PATH variable set. In DOS (not sure about Win95/NT)
there may be interactions between different settings for different
applications if they don't die in reversed starting order. Nevertheless,
my Win 3.11 machines at home have this sort of system and it works.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GO/! d- s++:+ a+ C++(++++) USBVLHI*++++$ P+ L++ E--- W++ N++ w--- O- V-
PS+
PE- Y+ PGP- t+ 5++ X+ R* tv+ b+ DI++ D G e(*) h++/-- r+++ y?
------END GEEK CODE BLOCK------

-----------------------------------------------------
Bob Hoekstra:   APL & Unix Consultant
                http://www.khamsin.demon.co.uk


-----------------------------------------------------



Sun, 02 Jan 2000 03:00:00 GMT  
 J: winexec problem?


Quote:

>> : of how to use batfiles from J because there is a better way of
>> : getting the environment vars in J now.

>> :    2!:5 'windir'
> That's pretty nifty, even though it doesn't do what I need done.  However,
> when I look through the help text or release notes for my copy of J (J 3.04
> A), I don't find anything in the 2!: series except 2!:0, 2!:1, and 2!:55,
> and the first two don't work under Windows (2!:55" provides a really quick
> bail-out from J with no exit prompting, I just discovered).

> So, is my copy of J out of date?  Where is 2!:5 (and any other such new
> foreigns, such as querying the registry --- well, I can always hint, can't
> I?) documented?

A fast growing product like J is always bound to be out of sync with the
documentation. It is much faster to put things into the product than writing
the documentation and keeping all that stuff up to date.

I remember when I was with IBM and we sure had a lot of resources there
we constantly had much more items in IC/1 than what was in the manuals.
The same was true with APL2.

Sometimes we did put things in intentionally in the product that went to the
customers but did not put it straight away into the manuals. We then let it
sneak out htat putting on a special swithc (NOSSW = Not Officially Supported SWitch)
then that customer could try the feature out. Because it was not yet in the documentation
it could easily be removed. It is sort of sneaky way of Beta testing special features.

Going through the motions of documenting a new feature is a long timeconsuming
process and involves a lot of people, testing and acceptance process. Sneaking in
a new feature is easy compared to that.

So feel free to use any feature that is not yet documented in any product but be
aware it is not documented and there is NO commitment to support it so it may
be removed.

Regarding the host connetions (2!:x) then I would like to see more of them
in J. As soon as you use Host features directly then portability goes out the
window. You already have this winexec thing in J so you can do most things
but it is seriously ineffective.
/Gosi



Sun, 02 Jan 2000 03:00:00 GMT  
 J: winexec problem?

Quote:
Bill Harris writes:
>I'm used to a Unix PATH variable that pretty much includes everything, so
>dealing with a severely truncated PATH under Windows feels different.  I
>recognize that NT can deal with longer PATH contents, but that means some
>configuration work on my part each time I install my application.  I was
>hoping someone had experience querying the registry under J to find those
>applications automatically.

>: of how to use batfiles from J because there is a better way of
>: getting the environment vars in J now.

>:    2!:5 'windir'

You can use the windows API to query the environment, e.g.

getenv=: verb define
mem=. >'kernel32 GetEnvironmentStringsA *c' 15!:0 ''
dat=. 15!:1 mem,0 1024

Quote:
> (<;._2 dat) -. a:

)

   getenv''
TEMP=C:\windows\TEMP                                                      

PROMPT=$p$g                                                                

winbootdir=C:\WINDOWS                                                      

COMSPEC=C:\WINDOWS\COMMAND.COM                                            

PATH=d:\J304;C:\WINDOWS\SYSTEM\;C:\WINDOWS...



Sun, 02 Jan 2000 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. JS-EAI with *JS*-callback

2. js.exception 3279.js

3. ST/V KernelDLL winExec:cmdShow: problem (help!)

4. Problems with WinExec

5. Problems with WinExec

6. Help with JS.Exception problems

7. WinExec Question

8. WinExec/PCL Tools/PTools CW Addons!

9. WinExec Template Kit

10. WinExec Template Kit

11. winexec templates

12. Using WinExec

 

 
Powered by phpBB® Forum Software