[9fans] ape pwd.h not in sync ?

[9fans] ape pwd.h not in sync ?

[prem]

Hi All,
the ape/pwd.h has the following
(in short pw_passwd missing, is this something unwanted ?)

struct passwd {
	char	*pw_name;
	uid_t	pw_uid;
	gid_t	pw_gid;
	char	*pw_dir;
	char	*pw_shell;
};


Linux has:
struct passwd
{
  char *pw_name;                /* Username.  */
  char *pw_passwd;              /* Password.  */
  __uid_t pw_uid;               /* User ID.  */
  __gid_t pw_gid;               /* Group ID.  */
  char *pw_gecos;               /* Real name.  */
  char *pw_dir;                 /* Home directory.  */
  char *pw_shell;               /* Shell program.  */
};

BSD:
struct passwd {
		   char    *pw_name;	   /* user name */
		   char    *pw_passwd;	   /* encrypted password */
		   uid_t   pw_uid;	   /* user uid */
		   gid_t   pw_gid;	   /* user gid */
		   time_t  pw_change;	   /* password change time */
		   char    *pw_class;	   /* user access class */
		   char    *pw_gecos;	   /* Honeywell login info */
		   char    *pw_dir;	   /* home directory */
		   char    *pw_shell;	   /* default shell */
		   time_t  pw_expire;	   /* account expiration */
};

Cheers,
/Prem

Re: [9fans] ape pwd.h not in sync ?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

it won't work, so it's better to find that out when
you compile the program rather than waste time compiling
it only to fail when run.

[-- Attachment #2: Type: message/rfc822, Size: 2919 bytes --]

From: prem <prem.mallappa@gmail.com>
To: 9fans@9fans.net
Subject: [9fans] ape pwd.h not in sync ?
Date: Wed, 17 Dec 2008 16:55:09 GMT
Message-ID: <35d1fb81-fc46-4938-bacd-32254ff345d6@o40g2000prn.googlegroups.com>

Hi All,
the ape/pwd.h has the following
(in short pw_passwd missing, is this something unwanted ?)

struct passwd {
	char	*pw_name;
	uid_t	pw_uid;
	gid_t	pw_gid;
	char	*pw_dir;
	char	*pw_shell;
};


Linux has:
struct passwd
{
  char *pw_name;                /* Username.  */
  char *pw_passwd;              /* Password.  */
  __uid_t pw_uid;               /* User ID.  */
  __gid_t pw_gid;               /* Group ID.  */
  char *pw_gecos;               /* Real name.  */
  char *pw_dir;                 /* Home directory.  */
  char *pw_shell;               /* Shell program.  */
};

BSD:
struct passwd {
		   char    *pw_name;	   /* user name */
		   char    *pw_passwd;	   /* encrypted password */
		   uid_t   pw_uid;	   /* user uid */
		   gid_t   pw_gid;	   /* user gid */
		   time_t  pw_change;	   /* password change time */
		   char    *pw_class;	   /* user access class */
		   char    *pw_gecos;	   /* Honeywell login info */
		   char    *pw_dir;	   /* home directory */
		   char    *pw_shell;	   /* default shell */
		   time_t  pw_expire;	   /* account expiration */
};

Cheers,
/Prem

Re: [9fans] ape pwd.h not in sync ?

[lucio]

> it won't work, so it's better to find that out when
> you compile the program rather than waste time compiling
> it only to fail when run.

It's an interesting philosophy, but it just bites you in a different
spot :-)

That said, it's obvious from the way the question was posed that there
is no single answer.

++L

Re: [9fans] ape pwd.h not in sync ?

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

in this case, i can't seen any point in providing pw_passwd
since no program that uses it (for anything non-trivial) could
work on Plan 9.   in fact, it's not even useful on unix systems:

	When  shadow(5)  passwords  are  enabled  (which  is  default  on  many
    GNU/Linux  installations)  the content of pw_passwd is usually not very
    useful. [because the contents are hidden in another file]

so: the program that refers to it won't be ported to plan 9,
and probably won't work on unix. best just to fix it by removing the reference.

[-- Attachment #2: Type: message/rfc822, Size: 2273 bytes --]

From: lucio@proxima.alt.za
To: 9fans@9fans.net
Subject: Re: [9fans] ape pwd.h not in sync ?
Date: Thu, 18 Dec 2008 17:21:04 +0200
Message-ID: <228339633bc8110d58678382179f6644@proxima.alt.za>

> it won't work, so it's better to find that out when
> you compile the program rather than waste time compiling
> it only to fail when run.

It's an interesting philosophy, but it just bites you in a different
spot :-)

That said, it's obvious from the way the question was posed that there
is no single answer.

++L