Aaron,
In message <apjabt$2evs$1@soapbox.cs.bham.ac.uk>, A.Sloman@cs.bham.ac.uk
writes
>I have had this question from Austin tate who has been playing with
>windows poplog V15.5
>
>> Is there a command that tells you the directory poplog or pop-11 is
>> set to as a base?
>
>
>On unix/linux it would be
> systranslate('usepop')=>
>
>but I expect that does not work on windows, and don't have time to try
>just now.
>
As I mentioned by email, systranslate('usepop')=> also works in Windows.
>> or one that lists the directories in the current directory?
>
>When I last tried ENTER dired, and ENTER ls,
>in windows poplog neither worked.
>
>Is there an alternative that does work?
>
I have looked at the case of Windows + Cygwin. Assuming Cygwin is
installed in C:\cygwin, then the following will work without any changes
to the ved_ls function.
'C:\\cygwin\\bin\\bash.exe' -> systranslate('SHELL');
followed by
<ENTER> ls <RETURN>
in the VED environment.
Of course, you need to check that in your installation of Cygwin, bash
is in /bin and not /usr/bin or some other place. I remember making some
specific changes to the structure of the Cygwin directories because an
earlier version managed to get them very muddled.
The assignment to SHELL can be made in Windows (using the system dialog
or SET command), or within Poplog initialisation in an init.p file.
Using the Cygwin resources, I expect that most of the VED extra commands
expecting to exec or pipe to an external command will work, as is, since
the default assumption is that the system is running in a Unix
environment.
At some point, the VED commands ought to be changed to provide explicit
support for native Windows. It might be better to avoid this wherever
possible by using a platform-neutral procedure. For example, ved_ls
could be rewritten to use sys_files_matching and sys_file_stat. It would
then work under any version (current or future) of Poplog and the
results could be made available in a pre-determined format that was not
platform dependent, suitable for use via an enumerator. However we do
this, the semantics for file specification on different platforms will
be a nuisance.
>If possible please copy replies to A.Tate AT ed.ac.uk
>
I'm not sure if I can cc: a news reply, but when I've finished looking
at the native Windows case, I'll send Austin a summary of both.
>I presume this may one day be fixed by the proposal to use cygwin
>to make unix/linux poplog work on windows.
>
It looks as if it is much easier to make existing code work with Cygwin
with a few configuration changes than to complete the migration of the
non-core code.
Next stop Poplog + Windows + Cygwin + X-Windows.
Regards,
--
Jeff
|