[SUGGESTION] Some lfs functionality in os library, please!

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[SUGGESTION] Some lfs functionality in os library, please!

Dirk Laurie-2
Every time I require lfs, I ask myself: why is this stuff not in the
os library?

I understand that not all systems support everything that lfs
has. And that Lua is very platform-independent.

But the goal of platform-independence does not stop Lua
from offering os.execute, which invites the user to write
platform-dependent code, and io.popen, which "is system
dependent and is not available on all platforms".

The absence of functions so basic that even CP/M and PC-DOS
had them is the one thing that stops Lua from breaking into
the Perl/Python cartel of scripted system programming.

If all of lfs is too much, here is my order of preference:

1. dir
2. chdir, mkdir, rmdir, currentdir
3. attributes, setmode, touch
4. lock, unlock, lock_dir
5. link, symlinkattributes

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Daurnimator
On 8 September 2016 at 00:40, Dirk Laurie <[hidden email]> wrote:
> Every time I require lfs, I ask myself: why is this stuff not in the
> os library?

Everytime I see the `os` library I ask: why did this come with lua? I
always replace it with my own variants anyway.

As the python community has slowly learned: the standard libraries are
where functions go to die. see
http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Abhijit Nandy
In reply to this post by Dirk Laurie-2
Yes, also pulling in another library for basic file operations is not always possible when shipping with minimal builds of Lua.

On Wed, Sep 7, 2016 at 8:10 PM, Dirk Laurie <[hidden email]> wrote:
Every time I require lfs, I ask myself: why is this stuff not in the
os library?

I understand that not all systems support everything that lfs
has. And that Lua is very platform-independent.

But the goal of platform-independence does not stop Lua
from offering os.execute, which invites the user to write
platform-dependent code, and io.popen, which "is system
dependent and is not available on all platforms".

The absence of functions so basic that even CP/M and PC-DOS
had them is the one thing that stops Lua from breaking into
the Perl/Python cartel of scripted system programming.

If all of lfs is too much, here is my order of preference:

1. dir
2. chdir, mkdir, rmdir, currentdir
3. attributes, setmode, touch
4. lock, unlock, lock_dir
5. link, symlinkattributes


Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Peter Aronoff
In reply to this post by Daurnimator
Daurnimator <[hidden email]> wrote:
> As the python community has slowly learned: the standard libraries are
> where functions go to die. see
> http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/

I often see similar thoughts expressed for Ruby and Perl.

However. Ruby, Perl, and Python are large languages that come with (a lot
of) batteries. They all share a culture of using non-standard libraries.
That is, people make heavy use of CPAN, gems, pip & company. Lua is a tiny
language withot batteries (for the most part, or “with minimal batteries”
if you prefer). It has a culture of “write your own” and “no dependencies”.
So what makes sense for the big trio might not make sense for Lua.

Bottom line: I don’t think problems with other standard libraries are
a knockdown argument against including some (relatively?) basic os-related
functions into Lua’s small stdlib.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Paul Moore-3
On 7 September 2016 at 16:00, Peter Aronoff <[hidden email]> wrote:
> Bottom line: I don’t think problems with other standard libraries are
> a knockdown argument against including some (relatively?) basic os-related
> functions into Lua’s small stdlib.

OTOH, if the suggested libraries are inappropriate (for whatever
reason) in a particular application, it's much harder to omit/disable
them if they are in the stdlib. I had this problem very recently, the
os functions don't handle Unicode correctly on Windows (nor does print
for that matter) and it's a real pain to disable them.

Looking at the OP's first suggestion, does lfs.dir correctly handle a
directory containing a filename that's not encodable in the current
codepage on Windows? Sure it's (to an extent) a specialist case, but
it matters a lot to some applications.

There's a trade-off here. If it's easy to ignore a library (just don't
use it) then it's OK for it to not cover all cases. But if it's hard
to ignore it (it's built into the language or stdlib) then you have a
greater responsibility to work correctly for all your users. Of course
Lua already defers to the CRT for whether things like getenv, popen,
io or print are "correct". But once we get out of the C standard
library, things get progressively murkier.

Paul

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Dirk Laurie-2
2016-09-07 17:23 GMT+02:00 Paul Moore <[hidden email]>:

> There's a trade-off here. If it's easy to ignore a library (just don't
> use it) then it's OK for it to not cover all cases. But if it's hard
> to ignore it (it's built into the language or stdlib) then you have a
> greater responsibility to work correctly for all your users.

There's a neat way past that, used by texlua (the Lua interpreter
that ships with LuaTeX).

It has about a dozen extra libraries preloaded (including lfs and lpeg),
but not in _G, which looks like that of standard Lua. You must still
require them, but you don't need them installed elsewhere.

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Aapo Talvensaari
In reply to this post by Daurnimator
On 7 September 2016 at 17:53, Daurnimator <[hidden email]> wrote:
On 8 September 2016 at 00:40, Dirk Laurie <[hidden email]> wrote:
> Every time I require lfs, I ask myself: why is this stuff not in the
> os library?

Everytime I see the `os` library I ask: why did this come with lua? I
always replace it with my own variants anyway.

Any examples? Lua only or Lua + C module?
 
As the python community has slowly learned: the standard libraries are
where functions go to die. see
http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/

Once, I was a programmer writing C#. The language evolved hugely over the time
that it didn't almost look like a same language after a few versions. But Lua is a
different, its syntax hasn't changed a much in years (5.1 is still mainstream, and
was released over ten years ago). Nor its libraries. Some changes here and there,
but quite stable still. What I mean is that with Lua those modules would not rot as
much as with other languages. And we all mostly talking here about single static
functions. I'm not sure how having os.dir / fs.dir or something would suck anyone's
air as the article puts it out. We are not talking here about having HTTP(S) client
implemented as a standard Lua library.

I kinda agree with Dirk. I understand also that allowing people write OS dependent
code is not exactly the same as having (more) OS dependent code added in Lua
sources. But I also have to agree that some batteries should be provided in a year
of 2016.
Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Daurnimator
On 8 September 2016 at 01:44, Aapo Talvensaari
<[hidden email]> wrote:

> On 7 September 2016 at 17:53, Daurnimator <[hidden email]> wrote:
>>
>> On 8 September 2016 at 00:40, Dirk Laurie <[hidden email]> wrote:
>> > Every time I require lfs, I ask myself: why is this stuff not in the
>> > os library?
>>
>> Everytime I see the `os` library I ask: why did this come with lua? I
>> always replace it with my own variants anyway.
>
>
> Any examples? Lua only or Lua + C module?

Instead of os.date or os.time I use luatz https://github.com/daurnimator/luatz
  - usually I want time more accurate than to the second (this is an
optional part of luatz, and is the only bit that requires C code)
  - timezones are important!
(Infact, usually when someone reaches for `os.time()` they actually
wanted a monotonic clock)

Instead of os.execute I use lua-spawn https://github.com/daurnimator/lua-spawn

os.rename doesn't work across file systems
  - usually just shell out (with lua-spawn) to `mv`

os.getenv isn't powerful enough:
Almost everytime I need it I either need to enumerate all env vars, or
follow it up with a setenv
For setenv, lately I've been using lunix: https://github.com/wahern/lunix
Before that, lposix
Before that, lua-ex http://lua-users.org/wiki/ExtensionProposal

----------------------------

Remembering that prompts me: aren't the functions dirk proposes almost
exactly the lua-ex api?
**feelings of deja vu**

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Dirk Laurie-2
2016-09-07 18:01 GMT+02:00 Daurnimator <[hidden email]>:

> Remembering that prompts me: aren't the functions dirk
> proposes almost exactly the lua-ex api?
> **feelings of deja vu**

I'm not proposing any new functions, I'm just arranging the ones
already in lfs in order of preference. I.e. if I can have only one,
it's the dir iterator. If I can have more, the suite of directory functions
makes an all-or-none group. Etc.

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Steve Litt
In reply to this post by Daurnimator
On Thu, 8 Sep 2016 00:53:52 +1000
Daurnimator <[hidden email]> wrote:

> On 8 September 2016 at 00:40, Dirk Laurie <[hidden email]>
> wrote:
> > Every time I require lfs, I ask myself: why is this stuff not in the
> > os library?  
>
> Everytime I see the `os` library I ask: why did this come with lua? I
> always replace it with my own variants anyway.
>
> As the python community has slowly learned: the standard libraries are
> where functions go to die. see
> http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/

Fair enough.

Then why not have a Lua community curated, approved and documented
auxiliary library, with a package naming convention such that, assuming
distros follow that naming convention, you can pick any or all of that
auxiliary library?

<personal_opinion>
I think Lua is *by far* the best language in the world. So why do I use
Python almost exclusively these days? It's because I know if I start a
project in Python, I'll be able to complete it. Python has a well
curated set of libraries so that whether my need is XML parsing, SNMP,
YAML, HTTP requests, or pretty much anything else, my language provides
the stuff too techy for me to write from scratch. With Lua, I get no
such guarantee. I might not find the needed library, or I might need to
pick among three of them that do part of the job, and kludge the final
10% that none of the libraries give me.

I understand that I'm nowhere near representative of Lua users. I have
little interest in writing games, firmware, C-Lua interfaces, and the
like. I write plain old computer applications, which is where you need
better libraries. And because I'm atypical, my needs shouldn't
determine what gets thrown on the computer when you install Lua. As one
person posted: "pulling in another library for basic file operations is
not always possible when shipping with minimal builds of Lua."

Dirk wrote the following:

==========================================================
The absence of functions so basic that even CP/M and PC-DOS
had them is the one thing that stops Lua from breaking into
the Perl/Python cartel of scripted system programming.
==========================================================

I'm a piece of anecdotal evidence to the preceding assertion. I was
firmly in the Lua fold for two years, but every time I started a
project, I had to figure out whether I could finish it in Lua, and if
not, I had to do it in Python. Eventually I just switched to the Python
part of the Perl/Python/Ruby cartel. There are probably a million more
like me.

So what's the benefit of bringing in people like me? More minds, more
coding ideas, and more (non-core) libraries. More people to identify
and fix problems. More visibility, more day jobs using Lua.

Please understand, I like the Lua language just the way it is, and
hope that in the year 2216 it will still have exactly two complex
data types: Table and Metatable. I'm not advocating a change to the
language, nor am I advocating a change in what gets installed when you
install Lua. All I'm advocating is a well named set of Lua community
curated, documented and approved auxiliary libraries that can be
installed en-masse or a-la-carte, so that the person starting a project
in Lua can finish it in Lua without resorting to crazy hacks.
</personal_opinion>

SteveT

Steve Litt
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28



Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Javier Guerra Giraldez
On 7 September 2016 at 18:38, Steve Litt <[hidden email]> wrote:
> I think Lua is *by far* the best language in the world. So why do I use
> Python almost exclusively these days?


I agree.  Lua is the best _language_ and Python is the most
_practical_ development tool.

When I have control of the whole problem/environment/solution, then I
do it in Lua.  and most times, i _love_ the result. it can be
beautiful, concise, fast, innovative... it's so rewarding.

but when it's one part of a bigger thing, with many other similar,
complex, untractable parts, or when i don't understand the problem at
first, or when the specs are subject to the whim of some client, then
it's Python (or C, if i'm lucky).  Mostly because of the libraries.

But I don't pretend to know what could make it easier to choose Lua
most of the time.


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Russell Haley
In reply to this post by Aapo Talvensaari
On Wed, Sep 7, 2016 at 8:44 AM, Aapo Talvensaari
<[hidden email]> wrote:

> On 7 September 2016 at 17:53, Daurnimator <[hidden email]> wrote:
>>
>> On 8 September 2016 at 00:40, Dirk Laurie <[hidden email]> wrote:
>> > Every time I require lfs, I ask myself: why is this stuff not in the
>> > os library?
>>
>> Everytime I see the `os` library I ask: why did this come with lua? I
>> always replace it with my own variants anyway.
>
>
> Any examples? Lua only or Lua + C module?
>
>>
>> As the python community has slowly learned: the standard libraries are
>> where functions go to die. see
>> http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/
>
>
> Once, I was a programmer writing C#. The language evolved hugely over the
> time
> that it didn't almost look like a same language after a few versions.

This is an interesting comment because Microsoft is right now in the
process of taking the big fat .Net Framework (that I happen to love)
and breaking it down into a .Net Core platform with "extensions" that
can be retrieved in binary format via Nuget package manager. Sound
Familiar?

As Per Steve Litt:

> I think Lua is *by far* the best language in the world. So why do I use
> Python almost exclusively these days? It's because I know if I start a
> project in Python, I'll be able to complete it. Python has a well
> curated set of libraries so that whether my need is XML parsing, SNMP,
> YAML, HTTP requests, or pretty much anything else, my language provides
> the stuff too techy for me to write from scratch. With Lua, I get no
> such guarantee. I might not find the needed library, or I might need to
> pick among three of them that do part of the job, and kludge the final
> 10% that none of the libraries give me.
>
> I understand that I'm nowhere near representative of Lua users. I have
> little interest in writing games, firmware, C-Lua interfaces, and the
> like. I write plain old computer applications, which is where you need
> better libraries. And because I'm atypical, my needs shouldn't
> determine what gets thrown on the computer when you install Lua. As one
> person posted: "pulling in another library for basic file operations is
> not always possible when shipping with minimal builds of Lua."

This is my position right now as well. I just wanted some client
websocket functionality in 5.3. I have found four different libraries,
and only one of them "meets" my "requirements" (i.e. smell test) and
it doesn't build for 5.3 right now! But should websockets be part of
the base library? I don't think so because the reason I am using Lua
is it's so damn small and fast and light. A more experienced open
source developer said to me that Lua (like his favorite JimTickle)
applications become more dependent on the supporting libraries than
the core libraries. Clairvoyant!

I don't think this is a Lua issue. It's an open source issue. LuaRocks
go and Github go a long way to making other packages more manageable,
but the same problems exist everywhere. Getting more people to write
the code YOU want is hard! There is no one size fits all in software
so the only "practical" answer is to have a small core and build out
your tool chain accordingly. Don't think that MS is changing their
framework out of altruism...

Anyway, I'll be futzing with lua-websockets if anyone needs me. ;)

Russ

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Jerome Vuarand
In reply to this post by Paul Moore-3
2016-09-07 16:23 GMT+01:00 Paul Moore <[hidden email]>:
> Looking at the OP's first suggestion, does lfs.dir correctly handle a
> directory containing a filename that's not encodable in the current
> codepage on Windows? Sure it's (to an extent) a specialist case, but
> it matters a lot to some applications.

No, but the same problem applies to io.open. That's why I patch both
Lua [1] and LFS [2] in my Windows builds [3].

[1] https://bitbucket.org/doub/canopywater/src/tip/srcweb/lua-5.3.1/patches/
[2] https://bitbucket.org/doub/canopywater/src/tip/srcweb/luafilesystem-1.6.3/patches/
[3] http://piratery.net/lua/downloads/

Shameless plugs aside, I don't think Lua needs more stuff in the base
libs. Lua is maintained by a few guys on their spare time. Seeing how
releases are already quite infrequent, I don't think burdening them
with more stuff to maintain instead of improving and evolving the core
would benefit anyone.

The standard libs are already quite sufficient for a very common set
of use cases (manipulation of text files), and serve as an example of
good practices for people that want to expand that. I personnally do
everything in Lua, from MCU firmware to 3D rendering to build
scripting (and more). It takes a bit of effort, but all you really
need is to know C, and it gets easier and easier as your toolbox
expands.

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Dirk Laurie-2
2016-09-08 1:25 GMT+02:00 Jerome Vuarand <[hidden email]>:

> 2016-09-07 16:23 GMT+01:00 Paul Moore <[hidden email]>:
>> Looking at the OP's first suggestion, does lfs.dir correctly handle a
>> directory containing a filename that's not encodable in the current
>> codepage on Windows? Sure it's (to an extent) a specialist case, but
>> it matters a lot to some applications.
>
> No, but the same problem applies to io.open. That's why I patch both
> Lua [1] and LFS [2] in my Windows builds [3].
>
> [1] https://bitbucket.org/doub/canopywater/src/tip/srcweb/lua-5.3.1/patches/
> [2] https://bitbucket.org/doub/canopywater/src/tip/srcweb/luafilesystem-1.6.3/patches/
> [3] http://piratery.net/lua/downloads/
>
> Shameless plugs aside, I don't think Lua needs more stuff in the base
> libs. Lua is maintained by a few guys on their spare time. Seeing how
> releases are already quite infrequent, I don't think burdening them
> with more stuff to maintain instead of improving and evolving the core
> would benefit anyone.

I don't think lfs functions are left out of the standard libraries because
the Lua maintainers would find that an extra bother. I think it is because
the support libraries are not in core C, only in C compilers that support for
example Posix extensions.

I am not arguing for the stuff in luaposix, only for basic directory
awareness. Paths are essential to the package library anyway, so why
not in the os library where users can access them for another purpose
than finding modules?

> The standard libs are already quite sufficient for a very common set
> of use cases (manipulation of text files), and serve as an example of
> good practices for people that want to expand that.

They are very good for binary files too, now that string.pack/unpack
is available. Which makes it harder to understand why Lua can't DIR,
CHDIR, MKDIR, RMDIR. Every device that can read a USB stick
or SD card needs that functionality.

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Oliver Kroth
In reply to this post by Dirk Laurie-2


Am 07.09.2016 um 16:40 schrieb Dirk Laurie:

> Every time I require lfs, I ask myself: why is this stuff not in the
> os library?
>
> I understand that not all systems support everything that lfs
> has. And that Lua is very platform-independent.
>
> But the goal of platform-independence does not stop Lua
> from offering os.execute, which invites the user to write
> platform-dependent code, and io.popen, which "is system
> dependent and is not available on all platforms".
>
> The absence of functions so basic that even CP/M and PC-DOS
> had them is the one thing that stops Lua from breaking into
> the Perl/Python cartel of scripted system programming.
>
> If all of lfs is too much, here is my order of preference:
>
> 1. dir
> 2. chdir, mkdir, rmdir, currentdir
> 3. attributes, setmode, touch
> 4. lock, unlock, lock_dir
> 5. link, symlinkattributes
>
I know why i is not in the standard libs: it is not the same
functionality on all platforms.
And it can't be implemented for all platforms with same (or at least
similar) functionality.

Some platforms do not have a "current directory", so chdir and
currentdir are not defined there
Some do not even have directories. Good bye, mkdir and rmdir...
Locking may not be available
Same applies to links.
Attributes are different (archive bit vs. executable...)

I once had to implement a "FAT file system version" of lfs, without
current directory, links, and with different
file attributes at my job. Wasn't too difficult. And had to be done in
any case, as I doubt that
the OS I have to deal with is on the list of implementers'
favourites...(No, it's not any x86 architecture),
so it was unlikely that I would have found it being done already.

As a Lua user I understand that additional libraries may behave
different on different platforms, however
I would expect that the standard libs behave the same.

--
Oliver










Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Dirk Laurie-2
2016-09-08 8:15 GMT+02:00 Oliver Kroth <[hidden email]>:

> Some platforms do not have a "current directory", so chdir and currentdir
> are not defined there
> Some do not even have directories.

Could you tell us which those are?

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Oliver Kroth


Am 08.09.2016 um 08:18 schrieb Dirk Laurie:
> 2016-09-08 8:15 GMT+02:00 Oliver Kroth <[hidden email]>:
>
>> Some platforms do not have a "current directory", so chdir and currentdir
>> are not defined there
>> Some do not even have directories.
> Could you tell us which those are?
>
Nucleus OS from Mentor Graphics, e.g., does not have the concept of a
current directory.
The OS is merely a library being statically linked to the application to
a binary that runs on the bare metal.

Regarding directories: I meant actually directory trees or paths.
Think of CP/M, or the OS/360 which have drives (disks), but no concept
of sub-directory trees.

--
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Sean Conner
In reply to this post by Dirk Laurie-2
It was thus said that the Great Dirk Laurie once stated:

>
> I don't think lfs functions are left out of the standard libraries because
> the Lua maintainers would find that an extra bother. I think it is because
> the support libraries are not in core C, only in C compilers that support
> for example Posix extensions.
>
> I am not arguing for the stuff in luaposix, only for basic directory
> awareness. Paths are essential to the package library anyway, so why
> not in the os library where users can access them for another purpose
> than finding modules?

  Paths are incidental to the package library.  All it does is substitute
the name of a module into a string and opens it using the standard C library
routines.  It has no real understanding of "paths".

> > The standard libs are already quite sufficient for a very common set
> > of use cases (manipulation of text files), and serve as an example of
> > good practices for people that want to expand that.
>
> They are very good for binary files too, now that string.pack/unpack
> is available. Which makes it harder to understand why Lua can't DIR,
> CHDIR, MKDIR, RMDIR. Every device that can read a USB stick
> or SD card needs that functionality.

  I've checked Unix, MS-DOS (on the assumption that Windows is more or less
the same even 30+ years later, and I have way too much documentation about
it) and AmigaOS (because I have a ton of documentation about that, too) and
while all three or or less have similar semantics for MKDIR, RMDIR and
CHDIR, it's DIR where there the differences lie.

  Under Unix, you have opendir()/readdir()/closedir().  You call opendir(),
then repeatedly call readdir(), which returns the successive file names on
the directory.  When done, you call closedir().  This returns the "."
(current directory) and ".." (parent directory).  You also have wordexp()
(it is POSIX), which returns a list of filenames matching a pattern (also
glob() and fnmatch() which are variations on a theme).

  Under MS-DOS, you have FindFirstFile() and FindNextFile().  You have to
first call FindFirstFile() with a given pattern and attributes (hidden,
system, directory)---this returns the first filename; subsequent calls
require FindNextFile().  I don't think the parent and current directory are
returned; but someone more familiar with Windows can answer this.

  Under AmigaOS [3], you have options.  You can call ExAll() (Examine All;
you can return just the name, or name with a selection of other metadata).
You can call Examine() (think opendir()) then loop with ExNext()
(readdir()).  Or you have MatchFirst()/MatchNext()/MatchEnd(), which works
like MS-DOS.  There are separate calls to get the current directory and
parent directory (these don't have names under AmigaOS).

  The only reason I bring these up is to illustrate that there is more than
one way DIR is handled.  Pass in a pattern, and under Unix you might get
[1]:

> for file in fsys.gexpand("/tmp/*") do print(file) end
/tmp/1
/tmp/2
/tmp/langtranslate.lua
/tmp/md5.c
/tmp/modules
/tmp/rfc1751
/tmp/rfc1751.c
/tmp/signal-test.lua

  But that misses a few files on Unix:

> for file in fsys.gexpand("/tmp/.*") do print(file) end
/tmp/.
/tmp/..
/tmp/.ICE-unix
/tmp/.X0-lock
/tmp/.X11-unix
/tmp/.font-unix

  Assume looping through each issue, you get all the files:

> for file in fsys.dir("/tmp") do print(file) end
.X11-unix
rfc1751.c
rfc1751
md5.c
1
langtranslate.lua
.font-unix
2
modules
.ICE-unix
.X0-lock
signal-test.lua

but you get all the files [2] and any "globbing" must be added by the user
(and in the case of MS-DOS/Windows, duplicating what the operating system
can provide by default).  Or, you somehow provide for both operations (which
for MS-DOS could be the same function under two different names).  The
tricky part is defining the name(s) and what to expect.

  -spc (And for all three systems, renaming a file not only has a similar
        API, but all three have the same restriction that you can't rename
        across a disks)

[1] fsys is org.conman.fsys

        https://github.com/spc476/lua-conmanorg/blob/master/src/fsys.c

[2] Except for "." and ".." in this example, since I skip those.  I skip
        those in fsys.dir() because in all the code I've written, I never
        wanted to bother with "." and "..".

[3] AmigaDOS has the concept of drives like MS-DOS, but instead of just
        a single letter name like A:, it uses a longer name, such as DF0:
        (for floppy drive 0).  Not only can you use physical names like
        DF0:, but volume names like Steve: or MyHardDisk:.  If you specify a
        file like:

                TheGreatGame:config.txt

        AmigaDOS will prompt for TheGreatGame: volume if it isn't mounted.
        You can place TheGreatGame: disk in any drive, and AmigaDOS will
        automatically find it and open the file.

        You can also assign volume names to directories as well.  It's a
        really cool system.

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Sean Conner
In reply to this post by Oliver Kroth
It was thus said that the Great Oliver Kroth once stated:
>
> Regarding directories: I meant actually directory trees or paths.
> Think of CP/M, or the OS/360 which have drives (disks), but no concept
> of sub-directory trees.

  CP/M and MS-DOS 1.0 have *some* concept of a "current directory", only in
those cases, it's the "current drive" (each drive having just one top level
directory).  For those, you can simply return just the drive specification:

        A:
        B:
        etc

MS-DOS 2.0 and higher does have a concept of a "current directory" in
addition to a "current drive".

  For operating systems that don't even have a concept of a "current drive"
can simply return an empty string.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [SUGGESTION] Some lfs functionality in os library, please!

Aapo Talvensaari
In reply to this post by Oliver Kroth
On Thursday, 8 September 2016, Oliver Kroth <[hidden email]> wrote:
I know why i is not in the standard libs: it is not the same functionality on all platforms.

I'm pretty sure there is a platform where Lua doesn't even work, or some of its standard libs don't work. There must be, ;-).

I usually put Lua in a group of Perl/Pyrhon/Ruby/PHP/Javascript. All of these do have these basic filesystem calls in their base libraries. I do not hear a much complains about them being there. People who use esoteric platforms are probably aware of their choice, and the problems with it.

One thing is for sure, though. If Lua starts accepting new funtions or even whole new modules in its core, we are probably going to see a lot more of this kind of proposals. Well, 5.3 already accepted some core UTF-8 functionality in its utf8 module.

I believe there are too extremes. One extreme thinks that there is alredy too much in core. Other one thinks there is newer too much. I believe also that the first group is the bigger one. Could we just get something added? A few new core functions in each new release (Dirk proposal is a good start), not something like J2SE or .NET Framework.
12