Everything is a File - Revision history

Theresa.reneau at 00:40, 21 May 2014

2014-05-21T00:40:16Z

Theresa.reneau at 00:18, 21 May 2014

2014-05-21T00:18:44Z

Theresa.reneau at 00:16, 21 May 2014

2014-05-21T00:16:13Z

Laurel at 21:48, 20 July 2011

2011-07-20T21:48:01Z

Paulm: /* Unix File System as a Universal Name Space */

2011-03-10T02:05:49Z

Unix File System as a Universal Name Space

Paulm: /* Unix File System as a Universal Name Space */

2011-03-09T02:01:19Z

Unix File System as a Universal Name Space

Paulm at 00:41, 25 February 2011

2011-02-25T00:41:56Z

Paulm: /* Everything is a stream of bytes */

2011-02-23T19:32:40Z

Everything is a stream of bytes

Paulm: /* Everything is a stream of bytes */

2011-02-23T19:05:26Z

Everything is a stream of bytes

Paulm: /* Everything is a stream of bytes */

2011-02-17T21:07:27Z

Everything is a stream of bytes

@@ Line 1: / Line 1: @@
 {{Migrated}}
-[https://docs.google.com/document/d/1cGOtqI8izepaMrnS4b_otwGv5F7E2rotcTxIKz3eWJw/edit?usp=sharing editing Everything is a File]
+[https://docs.google.com/document/d/1cGOtqI8izepaMrnS4b_otwGv5F7E2rotcTxIKz3eWJw/edit?usp=sharing Google Drive Everything is a File]
 ''"On a UNIX system, everything is a file; if something is not a file, it is a process."''

← Older revision		Revision as of 00:18, 21 May 2014
Line 1:		Line 1:
−	{{~~Migrate~~}}	+	{{Migrated}}
	[https://docs.google.com/document/d/1cGOtqI8izepaMrnS4b_otwGv5F7E2rotcTxIKz3eWJw/edit?usp=sharing editing Everything is a File]		[https://docs.google.com/document/d/1cGOtqI8izepaMrnS4b_otwGv5F7E2rotcTxIKz3eWJw/edit?usp=sharing editing Everything is a File]

← Older revision		Revision as of 00:16, 21 May 2014
Line 1:		Line 1:
		+	{{Migrate}}
		+	[https://docs.google.com/document/d/1cGOtqI8izepaMrnS4b_otwGv5F7E2rotcTxIKz3eWJw/edit?usp=sharing editing Everything is a File]
		+
	''"On a UNIX system, everything is a file; if something is not a file, it is a process."''		''"On a UNIX system, everything is a file; if something is not a file, it is a process."''

← Older revision		Revision as of 21:48, 20 July 2011
Line 34:		Line 34:
	See [[Linux File System]] for much more info about the layout of the file system and what you typically find there.		See [[Linux File System]] for much more info about the layout of the file system and what you typically find there.

−	[[Category: Tech support]] [[Category: ~~Education~~]] [[Category: Tech training]]	+	[[Category: Tech support]] [[Category: Classes]] [[Category: Tech training]]

@@ Line 32: / Line 32: @@
 Today the Unix File System name space is universally recognized, even it is not known as such, it forms the basis of a URL e.g.  http://www.freegeek.org/volunteer/. Unix and Linux  file systems tend to be alike (though there are exceptions e.g. Mac OS X). There is a well established, coherent layout for files that has been replicated across many different varieties of Unix and Linux (parts of it can even be seen on some mobile phones). This makes them easy to work on as they are familiar and do not tend to change from machine to machine. Having a clear, consistent, hierarchy of files and directories provides a mechanism for addressing a resource regardless of its nature. E.g. you can refer to a directory as <code>/home/oem</code>, a file as <code>/home/oem/example.pdf</code>, a hard disk as <code>/dev/sda1</code> a mouse as <code>/dev/mouse</code> etc. It also means that if you add a resource such as a hard drive it can be placed anywhere in the file hierarchy, not just at the root level. This is very flexible in contrast to sat, the drive letter system historically used by Windows where each drive appeared as a separate entity without a useful label. A hard drive to Unix appears transparent to the end user. For example you could mount a harddrive as <code>/home/oem/Music</code> and it would act just like an ordinary directory.
-See [[File System Hierarchy]] for much more info about the layout of the Linux File System and what you typically find there.
+See [[Linux File System]] for much more info about the layout of the file system and what you typically find there.
 [[Category: Tech support]] [[Category: Education]] [[Category: Tech training]]

← Older revision		Revision as of 00:41, 25 February 2011
Line 18:		Line 18:

	* Unix Domain sockets: These enable two processes on the same computer to communicate (especially client server relations). They are similar to named pipes but are full duplex (i.e. information can flow both ways) and allow for datagrams a --- discrete packets of data. This means that more than one client can connect to a server for example. They are also connectionless --- programs can communicate without have to keep the connection open. Despite the name they have very little to do with networking. Because they are treated as files security can be implemented by using standard file permissions.		* Unix Domain sockets: These enable two processes on the same computer to communicate (especially client server relations). They are similar to named pipes but are full duplex (i.e. information can flow both ways) and allow for datagrams a --- discrete packets of data. This means that more than one client can connect to a server for example. They are also connectionless --- programs can communicate without have to keep the connection open. Despite the name they have very little to do with networking. Because they are treated as files security can be implemented by using standard file permissions.
		+	* Named Pipes (a.k.a. FIFO pipes): These also allow for inter-process communication like domain sockets. They are more limited but simpler to deal with. Much like an actual water pipe they allow a one way flow fron one place to another. Two processes can access a pipe --- one to write to it, one to read it. They are explicity created using the <code>mkfifo</code> command.
		+	mkfifo named_pipe
		+	gzip -c < named_pipe > out.gz
		+	cat my_file > named_pipe
		+	rm named_pipe # deletes pipe as anyother file
		+
		+	Note here gzip is only reading from the pipe, it is writing to the file <code>out.gz</code>.
		+
		+	Pipes only work when they are connected at both ends. This is a usefull property as you can feed the output of a command to a pipe and it will only execute when something is connected to the other end to read from it (and vice versa).
		+
		+	==Unix File System as a Universal Name Space==
		+
		+	Today the Unix File System name space is universally recognized, even it is not known as such, it forms the basis of a URL e.g. http://www.freegeek.org/volunteer/. Unix and Linux file systems tend to be alike (though there are exceptions e.g. Mac OS X). There is a well established, coherent layout for files that has been replicated across many different varieties of Unix and Linux (parts of it can even be seen on some mobile phones). This makes them easy to work on as they are familiar and do not tend to change from machine to machine. Having a clear, consistent, hierarchy of files and directories provides a mechanism for addressing a resource regardless of its nature. E.g. you can refer to a directory as <code>/home/oem</code>, a file as <code>/home/oem/example.pdf</code>, a hard disk as <code>/dev/sda1</code> a mouse as <code>/dev/mouse</code> etc. It also means that if you add a resource such as a hard drive it can be placed anywhere in the file hierarchy, not just at the root level. This is very flexible in contrast to sat, the drive letter system historically used by Windows where each drive appeared as a separate entity without a useful label. A hard drive to Unix appears transparent to the end user. For example you could mount a harddrive as <code>/home/oem/Music</code> and it would act just like an ordinary directory.
		+
		+	See [[File System Hierarchy]] for much more info about the layout of the Unix File System and what you typically find there.
		+
		+	[[Category: Tech support]] [[Category: Education]] [[Category: Tech training]]

@@ Line 14: / Line 14: @@
 * Directories: lists of other files.
-* Special files: most of these are in <tt>/dev/</tt>. They are often used for input and output for example <code>/dev/input/mice</code> and there are also special files that have a particular purpose e.g. <code>/dev/random</code> exists as a source of randomness and  <code>/dev/full</code> exists so programmers can testo see what happens if a disk is full. (try <code>echo "I ate too many donuts" > /dev/full).
+* Special files: most of these are in <tt>/dev/</tt>. They are often used for input and output for example <code>/dev/input/mice</code> and there are also special files that have a particular purpose e.g. <code>/dev/random</code> exists as a source of randomness and  <code>/dev/full</code> exists so programmers can testo see what happens if a disk is full. (try <code>echo "I ate too many donuts" > /dev/full</code>. If you are on a diet, just route it to <code>/dev/null</code> instead).
 * Links: files that are a link to another file (or directory). These allow them to be seen elsewhere or under a different name. Most often we talk about and use symlinks, these have the advantage that if you delete a symlink the original doesn't also get deleted.
 * Unix Domain sockets: These enable two processes on the same computer to communicate (especially client server relations). They are similar to named pipes but are full duplex (i.e. information can flow both ways) and allow for datagrams a --- discrete packets of data. This means that more than one client can connect to a server for example. They are also connectionless --- programs can communicate without have to keep the connection open. Despite the name they have very little to do with networking. Because they are treated as files security can be implemented by using standard file permissions.

← Older revision		Revision as of 19:05, 23 February 2011
Line 17:		Line 17:
	* Links: files that are a link to another file (or directory). These allow them to be seen elsewhere or under a different name. Most often we talk about and use symlinks, these have the advantage that if you delete a symlink the original doesn't also get deleted.		* Links: files that are a link to another file (or directory). These allow them to be seen elsewhere or under a different name. Most often we talk about and use symlinks, these have the advantage that if you delete a symlink the original doesn't also get deleted.

−	*	+	* Unix Domain sockets: These enable two processes on the same computer to communicate (especially client server relations). They are similar to named pipes but are full duplex (i.e. information can flow both ways) and allow for datagrams a --- discrete packets of data. This means that more than one client can connect to a server for example. They are also connectionless --- programs can communicate without have to keep the connection open. Despite the name they have very little to do with networking. Because they are treated as files security can be implemented by using standard file permissions.

← Older revision		Revision as of 21:07, 17 February 2011
Line 11:		Line 11:
	It can be even said that Unix even treats the user as file. At the command line user interaction consists of reading and inputting a stream of text. More specifically Unix is centered around three standard input/output streams: ''standard input'' (<code>stdin</code>), ''standard output'' (<code>stdout</code>) and ''standard error'' (<code>stderr</code>).		It can be even said that Unix even treats the user as file. At the command line user interaction consists of reading and inputting a stream of text. More specifically Unix is centered around three standard input/output streams: ''standard input'' (<code>stdin</code>), ''standard output'' (<code>stdout</code>) and ''standard error'' (<code>stderr</code>).

−	Most files in Unix are ''regular files'': they contain regular data	+	Most files in Unix are ''regular files'': they contain regular data e.g. text files, images, executables or program input/output. There are exceptions however. These are things that can be said to be "more than files", that is things that have special properties although they can also be treated as regular files e.g. viewed with <code>ls</code>. They are:
		+
		+	* Directories: lists of other files.
		+	* Special files: most of these are in <tt>/dev/</tt>. They are often used for input and output for example <code>/dev/input/mice</code> and there are also special files that have a particular purpose e.g. <code>/dev/random</code> exists as a source of randomness and <code>/dev/full</code> exists so programmers can testo see what happens if a disk is full. (try <code>echo "I ate too many donuts" > /dev/full).
		+	* Links: files that are a link to another file (or directory). These allow them to be seen elsewhere or under a different name. Most often we talk about and use symlinks, these have the advantage that if you delete a symlink the original doesn't also get deleted.
		+
		+	*