Re: "Too long" error due to command line
[email protected] (Nicholas Clark) Thu, 30 Dec 1999 16:37:46 +0000
| Newsgroups | perl.riscos |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Dec 30, 1999 at 03:22:38PM +0100, Vincent Lefevre wrote: > On 30 Dec, Nicholas Clark <[email protected]> wrote: > > > Moving/symlinking either/both the perl script or the perl binary nearer to > > $ will work around the problem for a bit by making the paths shorter. > > I defined a *$Path variable, and used a pseudo-filing system. > But the problem with this is that I can no longer drag'n-drop > the filename to the taskwindow, otherwise the full pathname > would be written. Not sure what to do. Hopefully I've got the diagnosis of the cause correct. If so I think that you're going to have to bodge it, and how you bodge it will depend on exactly what/how your doing whatever your are doing. > > I believe that RISC OS 4 raises the OSCLI limit from 255 to 1023 characters. > > This is still ridiculous... Regrettably so. As are some other features of RISC OS [eg DDEUtils is designed to give multiple current directories to multiple task windows, but in turn managed to create a new global object - a single extended command line for the whole machine. D'oh] > > If you're not calling your perl script from an obey file you might be best > > to investigate the DDEUtils module and the extended command line that it > > provides. perl (courtesy of UnixLib) will automatically read these, so all > > you'd need to do is make the calling program set an extended command line. > > There was no calling program. I typed the command from a taskwindow. > But can LineEditor use this extended command line? I think it comes with source code, so it would be possible to add support if it doesn't currently have it. However, all it does is hook into the OS_ReadLine vector, so if (as I suspect) it's being called by the OS with a 255 limit (and a 255 buffer allocated by the OS) it's not going to help by modifing LineEditor; you'd need to find/make an alternative Taskwindow that allocates a big buffer, calls OS_ReadLine (and thereby LineEditor) with the big buffer, and then circumvents the OSCLI limit of 255 by using DDEUtils. Not nice Nick