File management

[nuclearfall]

I know it's currently possible to open file-streams that exist. Is it possible to create new files, view folder contents. Would this require adding new dependencies?

[vygr]

It is possible to save a string direct to a file using (save). So to save the edit buffer file out you could do.

(save (apply cat text_buf) "path...")

That will over-right and truncate what's there with the new data.

At the moment the whole issue of what to do about the ChrysaLisp file service is a bit up in the air, so the very idea of directories and folders and getting a directory listing doesn't exist. Only primitive (save) and (load) of a string. Even the (file-stream) function is currently faked to be (string-stream (load "filename"))...

We could add the idea of getting a string of the filename in a folder to the C main.c file if we absolutely have to. So we could implement a file browser/picker. But this starts to make assumptions about what the file system is and tying it to what the current hosts do.

I'd use the (save) hack above for now. The filesystem is going to have to be done as a service and it needs to live on the CPU that has the file system resource, there's no guarantee that the CPU that your process is running on has any drives etc...so it's a bit involved to do the full correct thing now.

I could be persuaded to add the 'get string of files in path' host call as a temporary helper.

[nuclearfall]

I gave this some thought.

To add some basic level of persistence I might create a user directory and an inc file that lists the contents. New files are written to that directory and appended to the list. Saved files can only be saved to the user directory—hopefully avoiding system breakage. We can write lisp files from inside and run them from the terminal.

We just don't make commits from that directory.

No decisions to be made about filesystems or any unnecessary reliance on the host system.

[vygr]

Actually that save line would be:

(save (join text_buf (ascii-char 10)) "path...")

as you want to add the LF between each line, they are not stored in the text_buf.

[nuclearfall]

Would also need EOF, no? I implemented the pupa.inc for some basic customization. I'll get back on reading, writing, and creating files now that that's done. I'll get some kind of basic lists of files and directories as well.

[vygr]

Not strictly needing the EOF as such.

[nuclearfall]

EOF is a very odd, old thing, sorry.

[vygr]

Worth mentioning here that we now have:

(sys-pii-dirlist) function available. But I would use it sparely ! It's a bit of a stop gap till a 'real' filesystem shows up. But now it has arrived, for host dir listing.

I've already used it to add tab completions to the GUI Terminal and created a standard Files browser app and File picker process. There is also a very useful cmd app 'files.lisp' that can be used as a mini 'find-grep' to ease command line batch use of tools like tocpm.lisp.

Using the File picker at least remove applications from the implementation of the folder structure of the host and eventual file system. But there is still just (save) and (load) of a string as the underlying file accessors.

[FrankC01]

Adding the equivalent of fstat for file/directory information would be useful. Like a supper set of Lisp probe-file:

(defq fi (probe-file "filename")) ; Return an emap with standard :keynames 
; :filename -> Fully qualified file name
; :filetype -> :file, :directory, :symbolic_link, etc.
; :fileage -> in nsecs since system epoc
; :filesize -> in bytes

[FrankC01]

@nuclearfall and @vygr lib/pathnode/pathnode.inc is starting to provide things noted above by constructing a sparse hierarchical file path by subclassing (in essence) lib/collections/xnode.inc.

Each node represents a path segment and each node can provide a listing of files and/or dirs as well as hidden files (prefixed with '.' and not a directory although it could be)

Nodes are built out as needed so it isn't quaffing vast memory usage unless you go there :)