Talk:Append a record to the end of a text file

Rationale

Basically I was looking for an example of appending an actual record to a file and found no such task.

(This was written by NevilleDNZ (Talk | contribs) at 10:59, 12 September 2011)

Still needs some work IMO; it's got lots of small bits and pieces jumbled together without quite a coherent story. It's probably not that hard to improve it to the point of being good though.

And as a side note, POSIX systems have the O_APPEND flag to the open() syscall which makes this trivial (if it is exposed by the language) provided appropriate flushing is used. (Even better, the flag is inheritable by subprocesses; that's a very useful thing at times.) By contrast, on Windows you need to lock the file to do this safely and that's error prone and much more complex in practice. Moreover, locks aren't inheritable (of course). Damn, but I wish the folks at Redmond actually understood all of POSIX properly, as it has some really wonderful things in there. –Donal Fellows 13:58, 12 September 2011 (UTC)

I am not sure I agree. As I understand it, under unix, locking is advisory -- you cannot enforce it on other programs, and only if every program accessing the file uses the same mechanism do locked files get protected (fcntl is one example but other mechanisms do get used, especially if people are attempting to support nfs). That said, if processes are designed so that collisions are rare, locking might not be necessary. Also, often unix's atomic file rename mechanism is used to avoid locking issues. Meanwhile, under windows, the default behavior is that only one program can have the file open for writing -- by default, you get an error when another program tries to open the file for writing. The windows behavior can be painful, and there's no atomic file rename, but any locking mechanism that gets enforced by the OS can be painful to work with. Meanwhile, all of these characteristics are properties of the operating system and not of the language. --Rdm 02:16, 13 September 2011 (UTC)

I'm under the same impression as Rdm. Is this about appending? Or some kind of record locking? Is it about append in native I/O facilities? I was also trying to understand the rationale behind the table and that the table has been left as somewhat vague. Normally, I would use a table for very specific results/observations and a bullet list for less specific results/observations. We are already seeing variations on the table content - which is fine if that's what's intended. For instance a couple of the solutions cite that they are guaranteed for multitasking, yet I don't see that they are doing anything other than relying on the o/s or library via open/close. --Dgamey 13:38, 26 September 2011 (UTC)

CSV?

Is it supposed to be a CSV file? The description doesn't say anything about the file format, unless "passwd" implies some sort of format. Maybe the given records should be specified in the description. --Mwn3d 23:57, 12 September 2011 (UTC)

Agreed. Will do.

The essence of the task is "Append a record to the end of a text file". Crudely speaking:

• A record is something that has multi fields.
• A text file is something that can be edited with "notepad"
  • in essence it does not contain "raw binary integers" etc.
  • The text file "record" represents the original record fields.

I want to avoid simply appending random text to the end of an arbitrary file as nominally programs are (concurrently) manipulating (and storing) structures of data.

NevilleDNZ 01:44, 13 September 2011 (UTC)

The given format does not look like CSV. While "colon-separated values" technically shortens to "CSV", CSV looks like this:

value11,value12,value13 with spaces,value14
value21,value22,value23,value24 with spaces

Commas are the only separator. The colons in the given format make it look like something else that we shouldn't call CSV. Is that what etc/passwd looks like? It would probably be best to say something like "the record's values are separated by commas, with values in composite items separated by commas (similar to Linux's /etc/passwd file)." If at all possible you might want to make the data structures involved in the record very very simple (i.e. no structs). That would make sure the focus is on what's in the task title. Stringifying a custom data structure is a different task (which we might not have yet...). --Mwn3d 02:23, 13 September 2011 (UTC)

This passwd file and linux or unix or posix passwd files would be best thought of as having records which have values which are separated by colons (and records are terminated by newlines). The contents of a certain value within each record can be thought of as having its own internal record structure which is separated by commas (and which cannot contain colons). --Rdm 17:32, 21 September 2011 (UTC)

Confused

Currently, the initial password file contents are specified as:

Source record field types and contents.

account	password	UID	GID	fullname,office,extension,homephone,email	directory	shell
string	string	int	int	struct(string,string,string,string,string)	string	string
jsmith	x	1001	1000	Joe Smith,Room 1007,(234)555-8917,(234)555-0077	jsmith@rosettacode.org	/home/jsmith
jdoe	x	1002	1000	Jane Doe,Room 1004,(234)555-8914,(234)555-0044	jdoe@rosettacode.org	/home/jsmith

But this conflicts with the usual password file format

Specifically the sixth field is supposed to be the home directory, and not an email address. Email address goes in the fifth field. And the seventh field is supposed to be the user's shell, and not their home directory. Also, two users with different user ids should not share the same home directory

So I think the initial contents should have been specified as:

Source record field types and contents.

account	password	UID	GID	fullname,office,extension,homephone,email	directory	shell
string	string	int	int	struct(string,string,string,string,string)	string	string
jsmith	x	1001	1000	Joe Smith,Room 1007,(234)555-8917,(234)555-0077,jsmith@rosettacode.org	/home/jsmith	/bin/bash
jdoe	x	1002	1000	Jane Doe,Room 1004,(234)555-8914,(234)555-0044,jdoe@rosettacode.org	/home/jdoe	/bin/bash

Something similar applies for the appended record. --Rdm 02:26, 13 September 2011 (UTC)