Yes, sure, that is possible. Then I would also have to do that in libdir.c and any other place that relies on sys_libdir being an absolute directory.
This will also make relative paths in [declare -stdpath] have different behavior based on whether sys_libdir is relative or not. If sys_libdir is absolute, then canvas_open() will use that path, if sys_libdir is relative, then canvas_open() will append the parent canvas' current dir. That's a bug with using realpath() prevents.
(which reminds me, I wrote a false comment in canvas_open(), "if not absolute path, append Pd lib dir" should read "if not absolute path, append parent canvas' current dir").
Also, I think that an API should provide a reliable interface that is as simple as possible, yet no simpler. sys_libdir is part of the Pd API, and insuring that it is _always_ absolute, rather than just "almost always" absolute, is an important difference.
If you want, I'll re-write the realpath() section according to the cert.org guidelines.
.hc
On May 23, 2008, at 9:23 PM, Miller Puckette wrote:
So... I'm sure this is a dead end, but is there some way [import] could be written to invoke realpath() so Pd doesn't have to?
cheers M
On Fri, May 23, 2008 at 02:07:58AM +0200, Hans-Christoph Steiner wrote:
If you really want to get into realpath():
https://www.securecoding.cert.org/confluence/display/seccode/FIO02-A. +Canonicalize+path+names+originating+from+untrusted+sources
.hc
On May 22, 2008, at 10:06 PM, Hans-Christoph Steiner wrote:
To quote the whole text:
Avoid using this function. It is broken by design since (unless using the non- standard resolved_path == NULL feature) it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing memory. And on the other hand pathconf () may return -1 to signify that PATH_MAX is not bounded.
I think whoever wrote that man page is really splitting hairs there, the FreeBSD/Mac OS X man page has no complaints about it. They are complaining that PATH_MAX _might_ not be defined. But on GNU/Linux, MinGW, and FreeBSD/Mac OS X, FILENAME_MAX _is_ defined. So just use FILENAME_MAX to allocate the buffer that realpath() uses (which was already happening anyway in s_main.c, but with MAXPDSTRING instead). It's a widely implemented POSIX function, how much more standard do you want? ;)
I think that Pd should give reliable information in the publically defined API (ok, s_stuff.h, but still). For example, it makes life easier in a lot of ways if you can count on sys_libdir being an absolute path, rather than making every other bit of code that might every use a path that is based on sys_libdir check to make sure that it is indeed absolute. The vast majority of the time, sys_libdir is an absolute path, and AFAIK, on Windows it is always an absolute path.
.hc
On May 22, 2008, at 9:44 PM, Miller Puckette wrote:
I finally realized realpath() is a pre-existing function. (I imagined it was sitting in another source file that didn't make it to the patch)
but.. "man realpath" says "Avoid using this function. It is broken by design..." so I'm sceptical of the idea. Anyway, why can't [import] just make the call if it needs it?
cheers M
On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner wrote:
The only real change to s_main.c in that path is the addition of realpath(). It seems that the function there is just copying the strings back and forth between sbuf and sbuf2, so I just added one more iteration of that back and forth for realpath().
.hc
On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
> I might have missed it, but I didn't see that realpath() itself > made it into > the patch... ? > > M > > On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner > wrote: >> >> The realpath() is definitely related. If you start Pd using a >> relative path, like I do when doing dev work (e.g. make && ../ >> bin/ >> pd), then sys_libdir will be a relative path. That means it is >> impossible to make absolute paths using sys_libdir, which is >> what I >> need to do to make [import] work, or loading libdirs with >> [declare - >> lib] and the libdir loader. >> >> I can't see any problems that realpath() might cause. >> >> .hc >> >> On May 22, 2008, at 8:45 PM, Miller Puckette wrote: >> >>> OK, I took most of the patch (not the "realpath()" call which >>> seems >>> unrelated) and uploaded to SVN, unless I'm mistaken. >>> >>> cheers >>> Miller >>> >>> On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph >>> Steiner >>> wrote: >>>> >>>> I was looking into this a bit more, and from what I can >>>> tell, the >>>> canvas-local path (ce_path) is always relative to the path >>>> of the >>>> parent patch. Here's the commit for pd-extended that adds >>>> support >>>> for absolute paths: >>>> >>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data? >>>> view=rev&revision=9862 >>>> >>>> Also, I submitted a patch: >>>> >>>> http://sourceforge.net/tracker/index.php? >>>> func=detail&aid=1917574&group_id=55736&atid=478072 >>>> >>>> .hc >>>> >>>> >>>> On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote: >>>> >>>>> >>>>> I think I fixed the full paths bug, here's the commit: >>>>> >>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data? >>>>> view=rev&revision=9856 >>>>> >>>>> .hc >>>>> >>>>> On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote: >>>>> >>>>>> >>>>>> I think this issue is pretty clear, and the languages that >>>>>> I know >>>>>> would fall along the lines of "each patch/abstraction has >>>>>> its own >>>>>> namespace" or in other words "#include only affects the >>>>>> one .c >>>>>> file", "import only affects the one .py file", etc. So I >>>>>> agree >>>>>> with Frank. Global settings are global, and canvas-local >>>>>> settings >>>>>> are local to the original file. >>>>>> >>>>>> The "semi-functional" part is the full paths that Marius >>>>>> mentioned. >>>>>> >>>>>> Then the other question is how to use something like "#X >>>>>> declare"/ >>>>>> canvas_savedeclarationsto() in externals. I'd like to >>>>>> create an >>>>>> [import] modelled after Python's import does, so I'd like >>>>>> to use >>>>>> "#X declare"/canvas_savedeclarationsto() with it. >>>>>> >>>>>> .hc >>>>>> >>>>>> On May 19, 2008, at 6:33 PM, Miller Puckette wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I use 'declare' all the time.. don't think it's >>>>>>> semifunctional at >>>>>>> all. >>>>>>> I think the questions about how declares should act inside >>>>>>> abstractions >>>>>>> are hard to resolve; in my own usage (and in the way I >>>>>>> suggest >>>>>>> others might >>>>>>> want to use declare) it's always in the main patch, as a >>>>>>> way to >>>>>>> show the >>>>>>> patch what libraries, etc, it needs. >>>>>>> >>>>>>> cheers >>>>>>> Miller >>>>>>> >>>>>>> On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph >>>>>>> Steiner >>>>>>> wrote: >>>>>>>> >>>>>>>> Hey, >>>>>>>> >>>>>>>> So I am diving into the whole canvas-local namespace and >>>>>>>> [declare] >>>>>>>> issue these days. I like the new "#X declare"/ >>>>>>>> canvas_savedeclarationsto() functionality, I think it >>>>>>>> could be >>>>>>>> useful >>>>>>>> for a lot of things. I was thinking of making an API to >>>>>>>> use >>>>>>>> it in >>>>>>>> externals, something like sys_register_loader(). I have >>>>>>>> two >>>>>>>> questions, first, how entrenched is the current >>>>>>>> behavior of >>>>>>>> [declare]? It currently is only semi-functional, and I >>>>>>>> think few >>>>>>>> people use it. >>>>>>>> >>>>>>>> The second is how to structure this for general use. I >>>>>>>> have >>>>>>>> thought >>>>>>>> of two ways: >>>>>>>> >>>>>>>> - make "declare" the key word and allow other >>>>>>>> objectclasses to >>>>>>>> have >>>>>>>> their own custom "#X declare" data. >>>>>>>> >>>>>>>> - allow objectclasses to register their own >>>>>>>> declaration key >>>>>>>> words, >>>>>>>> like [import] could have "#X import". >>>>>>>> >>>>>>>> The first would mean changing the behavior of [declare], >>>>>>>> the >>>>>>>> second >>>>>>>> could lead to a big mess... >>>>>>>> >>>>>>>> .hc >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------- >>>>>>>> -- >>>>>>>> ---- >>>>>>>> -- >>>>>>>> -- >>>>>>>> ----- >>>>>>>> ---- >>>>>>>> >>>>>>>> Man has survived hitherto because he was too ignorant to >>>>>>>> know >>>>>>>> how to >>>>>>>> realize his wishes. Now that he can realize them, he >>>>>>>> must >>>>>>>> either >>>>>>>> change them, or perish. -William Carlos Williams >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PD-dev mailing list >>>>>>>> PD-dev@iem.at >>>>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------- >>>>>> -- >>>>>> ---- >>>>>> -- >>>>>> -- >>>>>> ------- >>>>>> >>>>>> News is what people want to keep hidden and everything >>>>>> else is >>>>>> publicity. - Bill Moyers >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------ >>>>> -- >>>>> ---- >>>>> -- >>>>> -- >>>>> ------ >>>>> >>>>> You can't steal a gift. Bird gave the world his music, and >>>>> if you >>>>> can hear it, you can have it. - Dizzy Gillespie >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------- >>>> -- >>>> ---- >>>> -- >>>> --- >>>> ---- >>>> >>>> News is what people want to keep hidden and everything >>>> else is >>>> publicity. - Bill Moyers >>>> >>>> >>>> >>>> _______________________________________________ >>>> PD-dev mailing list >>>> PD-dev@iem.at >>>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> --------------------------------------------------------------- >> -- >> ---- >> --- >> ---- >> >> News is what people want to keep hidden and everything else is >> publicity. - Bill Moyers >>
--
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
--
If you are not part of the solution, you are part of the problem.
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne