4

A bunch of different software tools all use the Unix-specific pwd module and so are not runnable on Windows. The module only has a few functions associated with the user and the password file.

From first look it seems it would be something that could be duplicated on a Windows machine. As I can't find one I assume that there must be a show stopper.

Does anyone know what the technical challenge is in creating a Windows version of pwd module?

Velimir Mlaker
  • 10,664
  • 4
  • 46
  • 58
rick.it.2004
  • 231
  • 4
  • 11
  • 1
    lack of pwd command on widows is that reason – Tymoteusz Paul May 23 '15 at 14:24
  • 3
    @TymoteuszPaul. The unix `pwd` command has nothing to do with passwords - it simply prints the current working directory and is equivalent to `cd` (with no arguments) on Windows. – ekhumoro May 23 '15 at 16:13

1 Answers1

3

The way users are managed on Unix and its derivatives is very different from Windows, so a module that supported both would need a much higher level of abstraction.

As the documentation you linked to makes clear, the pwd module is basically just a wrapper around access to the standard /etc/passwd file, exposing its fields directly. A Windows system would have no equivalent for fields such as "shell" and "gecos", and conversely there would be attributes of a Windows user for which there would be no field, making any wrapper fairly pointless.

IMSoP
  • 89,526
  • 13
  • 117
  • 169
  • the point of the wrapper would be to abstract the details. In this case, is it possible to simply abstract the windows OS? – rick.it.2004 May 25 '15 at 18:32
  • @rick.it.2004 Abstract the details of what? I suppose you could treat the Windows SID as the UID, even though it's not an integer. But I'm struggling to think of a use case where a Windows wrapper that emulated `/etc/passwd` would be that useful, because most of the fields just have no equivalent. – IMSoP May 25 '15 at 20:15
  • The first throught is that you don't need to resolve the data into the wrapper into real data from the underlying OS, all you need to do is ensure that the functionality works the same. The mapping between the input data and the underlying OS would be managed in the wrapper. However, as I haven't looked into it in detail I don't know if this is possible. @IMSoP, do you know for sure this mapping isn't possible? – rick.it.2004 May 26 '15 at 06:44
  • 1
    @rick.it.2004 There is no functionality in that module other than looking up a few fields of data, so it's meaningless to talk of emulating behaviour. What would you advertise as a user's "shell" on Windows that would be in any way useful, let alone useful for the things a Unix-based script would expect it to he useful for. It all depends what existing scripts are using the module for, of course, but like I say I can't think of a use case where a wrapper would actually be useful. – IMSoP May 26 '15 at 08:06