If you're a Rubyist, you may already be familiar with object-oriented
designs. A running Unix/Unix-like kernel exposes two primary types of
objects to userspace:
1) Processes
2) Open files
Processes
---------
Processes are instances of running applications. Ruby programs
typically run as their own process[1] in userspace. Kernels expose
a Process IDentifier (PID) as positive integers to userspace programs
to uniquely identify processes.
Each PID represents one (private) process object in the OS kernel. The
PID is only a reference or pointer to that object. Two running
processes cannot have the same PID, and two PIDs cannot refer to the
same process, but PIDs can be recycled and reused over time.
PIDs are global in scope to each running Unix system.
Processes are created from its parent using the fork(2) system call
(which is wrapped by the Kernel#fork method in Ruby).
We will cover processes more in later chapters/posts.
[1] although experimental Multi-VM implementations exist that allow
multiple Ruby VMs within a single process
Open Files
----------
Running processes may create, open, and release objects known as "files"
in kernel space using APIs provided in user space. Much of Unix systems
programming revolves around manipulating "file" objects of various
types.
The kernel exposes non-negative integers known as "file descriptors" to
userspace. These are similar to PIDs as they are integers which point
to objects within the kernel.
You may have heard the term: "everything is a file" in Unix literature.
Indeed, each integer file descriptor may refer to one of several types
of objects within a running kernel. All of these objects can be called
"files" even if they're not stored on hard disks or visible on the
filesystem.
File descriptors may be reused and recycled within the lifetime a
process. They are more frequently recycled than PIDs.
Each process has its own file descriptor table (inherited from its
parent).
Unlike PIDs, several file descriptors may refer to the same file
object inside the kernel.
File descriptors have properties of their own that are not tied
to the underlying file object in the kernel.
As open files are the primary interface for processes to interact with
the kernel, I expect the majority of my future posts to cover various
aspects of file manipulation in-depth.
Summary
-------
Processes are containers for open files (among other things). Open
files are objects in the Unix kernel that can be accessed from within
processes.
License: GPLv3 (or later, at the discretion of Eric Wong)
http://www.gnu.org/licenses/gpl-3.0.txt
--
Eric Wong
Eric Wong <normalperson@yhbt.net> wrote: > If you're a Rubyist, you may already be familiar with object-oriented > designs. A running Unix/Unix-like kernel exposes two primary types of > objects to userspace: > > 1) Processes > 2) Open files Now that we know what filesystems and virtual filesystems are, several systems have a procfs virtual filesystem mounted under /proc. I don't believe it's standardized anywhere between different systems, but your system probably supports it. Among other things, procfs allows you to see the relationship between processes and their file descriptors on the filesystem. You can inspect which file descriptors a particular process is using by looking in the "fd" subdirectory belonging to the PID belonging to the process. For example, my current mutt process has PID=19245 and file descriptors 0, 1, 2, and 4 open: /proc/19245/fd /proc/19245/fd/0 /proc/19245/fd/1 /proc/19245/fd/2 /proc/19245/fd/4 Each PID has a directory in /proc/, and for each directory belonging to a particular PID, there is an "fd" Utilities like ps(1) (are likely to) use information found in procfs to generate its output. Other information in procfs is less-consistent across different implementations, so consult your OS documentation. License: GPLv3 (or later, at the discretion of Eric Wong) http://www.gnu.org/licenses/gpl-3.0.txt -- Eric Wong
On Fri, Sep 16, 2011 at 8:32 PM, Eric Wong <normalperson@yhbt.net> wrote: > Now that we know what filesystems and virtual filesystems are, several > systems have a procfs virtual filesystem mounted under /proc. I don't > believe it's standardized anywhere between different systems, but your > system probably supports it. Sadly, Mac OS X does not. When I want a similar tool there, lsof is super helpful: http://ph7spot.com/musings/leveraging-lsof James Edward Gray II
one more question about work on Mac OS X, i switch to work on MacX from Linux recently, and found lots of useful commands was missing. for example the "free" command. Do you guys have some advice for my situation? Thanks. On Sat, Sep 17, 2011 at 10:26 AM, James Gray <james@graysoftinc.com> wrote: > On Fri, Sep 16, 2011 at 8:32 PM, Eric Wong <normalperson@yhbt.net> wrote: > > Now that we know what filesystems and virtual filesystems are, several > > systems have a procfs virtual filesystem mounted under /proc. I don't > > believe it's standardized anywhere between different systems, but your > > system probably supports it. > > Sadly, Mac OS X does not. When I want a similar tool there, lsof is > super helpful: > > http://ph7spot.com/musings/leveraging-lsof > > James Edward Gray II > -- With Regards! Ye, Qian
On Sep 17, 2011 2:38 AM, "Qian Ye" <yeqian.zju@gmail.com> wrote: > > Do you guys have some advice for my situation? Please stop top-posting [1]. [1] http://catb.org/jargon/html/T/top-post.html
You should check out independent package managers like MacPorts (http://www.macports.org/) or Homebrew (http://mxcl.github.com/homebrew/). You may be able to get the utilities you're missing through one of those. On Sat, Sep 17, 2011 at 9:38 AM, Qian Ye <yeqian.zju@gmail.com> wrote: > one more question about work on Mac OS X, > i switch to work on MacX from Linux recently, and found lots of useful > commands was missing. for example the "free" command. Do you guys have some > advice for my situation? Thanks. > > On Sat, Sep 17, 2011 at 10:26 AM, James Gray <james@graysoftinc.com> wrote: >> >> On Fri, Sep 16, 2011 at 8:32 PM, Eric Wong <normalperson@yhbt.net> wrote: >> > Now that we know what filesystems and virtual filesystems are, several >> > systems have a procfs virtual filesystem mounted under /proc. I don't >> > believe it's standardized anywhere between different systems, but your >> > system probably supports it. >> >> Sadly, Mac OS X does not. When I want a similar tool there, lsof is >> super helpful: >> >> http://ph7spot.com/musings/leveraging-lsof >> >> James Edward Gray II > > > > -- > With Regards! > > Ye, Qian > >
thanks the tips Peter, i've tried these package managers, not as good as apt-get i think :-D On Sat, Sep 17, 2011 at 3:47 PM, Peter Mitchell <petmit@gmail.com> wrote: > You should check out independent package managers like MacPorts > (http://www.macports.org/) or Homebrew > (http://mxcl.github.com/homebrew/). You may be able to get the > utilities you're missing through one of those. > > On Sat, Sep 17, 2011 at 9:38 AM, Qian Ye <yeqian.zju@gmail.com> wrote: > > one more question about work on Mac OS X, > > i switch to work on MacX from Linux recently, and found lots of useful > > commands was missing. for example the "free" command. Do you guys have > some > > advice for my situation? Thanks. > > > > On Sat, Sep 17, 2011 at 10:26 AM, James Gray <james@graysoftinc.com> > wrote: > >> > >> On Fri, Sep 16, 2011 at 8:32 PM, Eric Wong <normalperson@yhbt.net> > wrote: > >> > Now that we know what filesystems and virtual filesystems are, several > >> > systems have a procfs virtual filesystem mounted under /proc. I don't > >> > believe it's standardized anywhere between different systems, but your > >> > system probably supports it. > >> > >> Sadly, Mac OS X does not. When I want a similar tool there, lsof is > >> super helpful: > >> > >> http://ph7spot.com/musings/leveraging-lsof > >> > >> James Edward Gray II > > > > > > > > -- > > With Regards! > > > > Ye, Qian > > > > > -- With Regards! Ye, Qian
> We will cover processes more in later chapters/posts.
Do you have an outline of the series available?
Great first entry. Thank you for this.
:F
Fogus <fogus@thinkrelevance.com> wrote: > > We will cover processes more in later chapters/posts. > > Do you have an outline of the series available? Not really. There'll be some inter-dependent topics that'll cause us to jump around some > Great first entry. Thank you for this. No problem! Feedback is greatly appreciated. I'm trying to strike good balance between the folks completely new to *nix and the more experienced folks who want to fill gaps in their knowledge. The latter group may have to wait a bit :x
On Tue, Sep 13, 2011 at 10:58 AM, Fogus <fogus@thinkrelevance.com> wrote: >> We will cover processes more in later chapters/posts. > > Do you have an outline of the series available? > > Great first entry. Thank you for this. > :F > Curious myself as well. Also if there was a mail list FAQ and/or wiki as these are written that would be great addition. This will be a great resource as the subject is currently under-documented in on the ruby end.
UNIXgod <unixgod@rubyprogrammer.net> wrote: > On Tue, Sep 13, 2011 at 10:58 AM, Fogus <fogus@thinkrelevance.com> wrote: > >> We will cover processes more in later chapters/posts. > > > > Do you have an outline of the series available? > > Curious myself as well. Also if there was a mail list FAQ and/or wiki > as these are written that would be great addition. This will be a > great resource as the subject is currently under-documented in on the > ruby end. Some folks on ruby-talk expressed interest in editing/mirroring it on their websites and/or putting it on a wiki somewhere. I won't be generating (or even reading) any HTML for this. Currently there's http://bogomips.org/usp.ruby/README to point people here and my original post ([ruby-talk:387469]). http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/387469 -- Eric Wong
On Tue, Sep 13, 2011 at 2:25 PM, Eric Wong <normalperson@yhbt.net> wrote: > UNIXgod <unixgod@rubyprogrammer.net> wrote: >> On Tue, Sep 13, 2011 at 10:58 AM, Fogus <fogus@thinkrelevance.com> wrote: >> >> We will cover processes more in later chapters/posts. >> > >> > Do you have an outline of the series available? >> >> Curious myself as well. Also if there was a mail list FAQ and/or wiki >> as these are written that would be great addition. This will be a >> great resource as the subject is currently under-documented in on the >> ruby end. > > Some folks on ruby-talk expressed interest in editing/mirroring it on > their websites and/or putting it on a wiki somewhere. I won't be > generating (or even reading) any HTML for this. > > Currently there's http://bogomips.org/usp.ruby/README to point people > here and my original post ([ruby-talk:387469]). > > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/387469 > > -- > Eric Wong > Sounds great Eric! If you'd be interested I can send you some code snippets from my talk which explain ruby embedded in a shell script for use like awk or perl( actually more like awk =) ). Feel free to shoot me an email if your interested in looking over the snippets for usage or inspiration. ~Stu
UNIXgod <unixgod@rubyprogrammer.net> wrote: > Sounds great Eric! If you'd be interested I can send you some code > snippets from my talk which explain ruby embedded in a shell script > for use like awk or perl( actually more like awk =) ). Feel free to > shoot me an email if your interested in looking over the snippets for > usage or inspiration. I often use ruby from shell scripts, too. Shell interaction is a bit high-level[1], but I was planning on tying it together with the implementations of IO.popen/open3. In general (and I might have not expressed this clearly), my flow of writing will be to focus on the low-level concepts first and then progress to the higher-level things that people interact with on a daily basis. [1] - Shell is Unix programming, but less systems programming from the shell programmer's standpoint. Of course a shell programmer benefits much from understanding things from a systems programming POV.