Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Peter Bex]

On Mon, Mar 18, 2013 at 10:05:46PM +0100, Felix wrote:
> I disagree. We can still try to make the core system practical,
> instead of a mindless API server for low-level facilities wrapped in
> s-expression syntax.

Nobody's arguing for that.  Abstraction (the right kind!) is what makes
Scheme so powerful.  However, convenience is not abstraction, it's
just more code.  And you know what's been said about piling feature
on top of feature :)

> So lets for once try to find a solution without
> just being polemic (well, polemics is great fun, of course, but in
> this case it doesn't help).

Seems a good idea.  I'm not arguing to argue, but because I want Chicken
to be a stable and secure system to do my programming in.  I'm sure
this goes for everyone.

> I suggest keeping the posix file-operations convenience-free (they
> duplicate a lot of the higher-level facilities anyway), while standard
> procedures and core-unit file-system operations could provide ...
> I barely dare to say it ... ~-expansion.

This would be even more confusing: some procedures would do expansion,
others would not.  That's especially annoying to newbies.  I think
the best compromise between convenience and control is to have
a procedure with a very short name, like Florian suggested.  We already
have QS and PP, why not add something like EP (for expand-pathname) to
unit extras?

Something like (with-input-from-file (ep "~/foo") read) seems alright
to me.  Not much hassle and explicit about what it's doing, especially
if the argument is actually a variable containing user input.

> How crazy. Remember SISC? It extended file-operations to cover all
> sorts of URIs in general.

This sounds alarmingly similar to PHP's infamous allow_url_fopen option.
It's generally advised to turn that off to fend off attacks.
See for example http://phpsec.org/projects/phpsecinfo/tests/allow_url_fopen

> Nobody ever complained, AFAICT.

Many critical bugs have been lying dormant for years or even decades.
For example, IIRC the bug that caused a recent shitstorm in Rails-land
due to arbitrary code execution in *any* Rails server had been in there
for 6+ years.

It's not a matter of programmers complaining, it's a matter of security
researchers putting their attention on a platform.  They're more likely
to do that on a platform once it's gained sufficient mainstream
popularity to be an interesting target.  SISC may wish it had such
popularity, but I'm sure if it did there'd be some pretty serious
problems with it.

> A bunch of programming languages special-case filename-syntax like "|...",
> running a command in a pipe. Quite convenient, I say, even if a bit of
> a hack (I'm not suggesting this particular kind of behaviour, of
> course. Just in case someone gets this wrong, which seems to be
> happening a lot, recently...).

It's a nasty hack.  Others doing things mind-bogglingly wrong doesn't
seem a good way to design your API.

Cheers,
Peter
-- 
http://www.more-magic.net