[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pubLynx reinstated LYNX-DEV
From: |
Jonathan Sergent |
Subject: |
Re: pubLynx reinstated LYNX-DEV |
Date: |
Mon, 07 Jul 1997 16:37:24 -0500 |
Foteos Macrides <address@hidden> wrote:
] I don't plan to use an LYExec() for Unix downloader and printer
] options, rather than just ensuring that the LYNXDOWNLOAD: and
] LYNXPRINT: URLs are the paths or scripts derived from lynx.cfg, with
] quote_path() applied to the arguments. With the adequate protections
] in place, I don't see any reason to block the Unix scripting capability,
] which is a much nicer way, for example, to get around zmodem/sz's
] inability to handle a second argument, than having to use an external
] script file with execl(). The DIRED stuff is using execl(), because
] that uses the paths defined in userdefs.h, and no scripts.
I don't see how not using system() and using scripting in downloader and
printer definitions are mutually exclusive. All that system()
does is execl("sh","-c",arg,(char *)0). Downloader definitions that
need shell processing (most of them, I guess) could have "sh -c"
prepended to them.
A more backward-compatible way to handle this would be to create
an EXECDOWNLOADER definition syntax of some sort that would run a
program with the given path with
execl(download_command->command, cp, cp1);
... this would allow system admins to create "secure" downloaders.
This is all a bit paranoid I suppose, but an ounce of prevention...
--jss.
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;