lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


See current definition of #, t[#t]~=nil and t[#t + 1]=nil. So in your
case there can be many values that can be returned. 100 is valid,
since there is a uid of 100 but not 101. In this case, '#' has little
usage for you.


On Mon, Dec 13, 2010 at 11:04 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Roberto Ierusalimschy once stated:
>> > The more I think about the alternatives for #t, the more I like the
>> > current choice :-)
>>
>> It is more or less like democracy ;)
>
>  And this point in the thread is as good as any for the following odd
> behavior I saw with Lua today (prompted by this discussion).  I have the
> following bit of code:
>
> local function etcpasswd()
>  local USERID = 1
>  local PASS   = 2
>  local UID    = 3
>  local GID    = 4
>  local NAME   = 5
>  local HOME   = 6
>  local SHELL  = 7
>
>  local users = {}
>  local f     = io.open("/etc/passwd","r")
>
>  for line in f:lines() do
>    local fields = str.split(line)
>    local user   = {}
>
>    user.userid = fields[USERID]
>    user.uid    = tonumber(fields[UID])
>    user.gid    = tonumber(fields[GID])
>    user.name   = fields[NAME]
>    user.home   = fields[HOME]
>    user.shell  = fields[SHELL]
>
>    users[user.userid] = user
>    users[user.uid]    = user
>  end
>
>  f:close()
>  return users
> end
>
> This returns a table of all the users on my development system (Linux) at
> home, keyed with both the userid (a string) and the UID (a number).  The
> UIDs range from 0 (for root) to 503 (for a regular user), but not
> consecutively (there are only 58 entries in the password file).  But now the
> odd part:
>
>> users = etcpasswd()
>> print(#users)
> 100
>
>  How odd.  Looking over my passwd file, I would actually expect #users to
> be 14, as UIDs 1 through 14 (actually 0 through 14) are in use; users[15]
> should be nil, and yes, it is:
>
>> print(#users[15])
> nil
>
>  Okay, how about:
>
>> for i = 1 , #users do
>>>print(users[i])
>>>end
> table: 0x8c0d598
> table: 0x8c0b870
> table: 0x8c21a90
> table: 0x8c0da30
> table: 0x8c20900
> table: 0x8c0d0c8
> table: 0x8c0d158
> table: 0x8c21248
> table: 0x8c20628
> table: 0x8c233f0
> table: 0x8c1e0e0
> table: 0x8c1e380
> table: 0x8c1e698
> table: 0x8c203c8
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> table: 0x8c1d598
> table: 0x8c27d60
> table: 0x8c27ab8
> nil
> table: 0x8c29d90
> table: 0x8c24568
> table: 0x8c1f438
> nil
> nil
> table: 0x8c1f180
> table: 0x8c2a020
> table: 0x8c242e0
> nil
> nil
> table: 0x8c1f890
> table: 0x8c26fe0
> table: 0x8c24a80
> nil
> table: 0x8c29ab8
> table: 0x8c27228
> table: 0x8c26d90
> nil
> nil
> nil
> table: 0x8c25648
> table: 0x8c1d2e8
> table: 0x8c24d00
> nil
> table: 0x8c25898
> nil
> nil
> nil
> table: 0x8c2a580
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> table: 0x8c27590
> table: 0x8c26ae8
> table: 0x8c23d78
> table: 0x8c1f600
> nil
> nil
> nil
> nil
> table: 0x8c24850
> table: 0x8c2a808
> table: 0x8c28140
> table: 0x8c1d060
> table: 0x8c2aaf0
> nil
> nil
> table: 0x8c1ebc8
> nil
> nil
> nil
> nil
> nil
> nil
> nil
> table: 0x8c28788
> nil
> nil
> table: 0x8c24fc8
> table: 0x8c28650
> nil
> table: 0x8c2a2d0
> nil
> table: 0x8c283a0
> table: 0x8c24020
> table: 0x8c1ef08
> table: 0x8c27810
>
>  Very interesting.
>
>  Now, for this case, I don't care if #users works or not as that's not a
> usecase I wrote the code for (I currently use it to print file ownerships;
> why all the other information?  Because I can, that's why) but I still find
> this interesting.  For the curious, here are the numeric values, in order
> they're inserted:
>
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 99 81 69 37 68 98 34 28 74 32 29 65534 47
> 51 77 48 23 67 43 38 42 66 100 25 24 39 49 92 76 97 93 89 41 27 33 95 55 75
> 78 500 501 502 503
>
>  -spc (So, how would any #t proposal work in the face of this?)
>
>
>