[erlang-questions] where is os:getuid() ?

[derek]

On Mon, Nov 23, 2015 at 11:09 AM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
> All hope is not lost however, since
>
> list_to_integer(string:strip(os:cmd("id -u"), right, $\n)).
>
> solves your problem. Granted, it performs worse than asking for the uid directly, but I've rarely seen a program who needed to manipulate uids otherwise, written in Erlang. May I ask what you are trying to do?

in rebar managed code, my building environment has different part
using different users, some file owner changes are due to `user
namespace`, run root with a normal user id, and need constantly fix
uid/gid by chown , or need to detect what is current user, trying to
implement in pure Erlang, but it seems Erlang doesn't have
os:getuid/0, neither os:chown/3. Workaround is to do that in shell /
python with Erlang os:cmd/1.

2> os:chown("abc", 1000, 100).
** exception error: undefined function os:chown/3

In this year Erlang factory they talked about to extend usage scenario
of Erlang, but this lack of POSIX interfaces might be a large
roadblock, continue Erlang's strength in long time running Internet
services, but for small tasks, short lived programs / daily useful
utilities, so far we only know erlc, rebar, ... and what else? mostly
are better in Shell / Python,

http://www.erlang-factory.com/sfbay2015/mike-williams

If Consider to add os:getuid/0 to Erlang, why not adopt a similar
strategy like Python os module, make it available for Unix only, no
need to care windows, that platform lacks a lot of POSIX calls,

https://docs.python.org/3/library/os.html

On Tue, Nov 24, 2015 at 2:50 AM, Daniel Abrahamsson
<daniel.abrahamsson@REDACTED> wrote:
> With the risk of sidetracking from the original question...
>
> At a theoretical level, I prefer separating functions implementing policies,
> and functions implementing mechanisms. "Mechanism" functions do one specific
> thing. There are no exceptions or corner cases. "Policy" functions, deal
> with the exceptions. They implement a policy, i.e. they make a specific
> decision on how to handle a certain case. As an example, "platform A has no
> user concept, so I will always return uid 0, which is root". Another policy
> function could implement the policy "platform A has no user concept, so I
> will throw an exception". When you confuse, or merge, the two, you limit the
> opportunity to implement other policies. If you have the "mechanism"
> functions, you can implement whatever policy suits you. If you only have the
> policy function, the corner cases are going to bite you somewhere down the
> road.