Be aware that two different paths foo. Iterates over and yields a new Pathname object for each element in the given path in ascending order. Returns the birth time for the file. If the platform doesn't have birthtime, raises NotImplementedError. Returns the children of the directory files and subdirectories, not recursive as an array of Pathname objects.
By default, the returned pathnames will have enough information to access the files. Note that the results never contain the entries. Returns clean pathname of self with consecutive slashes and useless dots removed. The filesystem is not accessed. This may retain more.. Removes a file or directory, using File.
Iterates over and yields a new Pathname object for each element in the given path in descending order. Iterates over the entries files and subdirectories in the directory, yielding a Pathname object for each entry.
Return the entries files and subdirectories in the directory, each as a Pathname object. The results contains just the names in the directory, without any trailing slashes or recursive look-up.
If you don't want. Since it is implemented by the standard library module Find, Find. If self is. Joins the given pathnames onto self to create a new Pathname object. Same as Pathname.
Note that this method does not handle situations where the case sensitivity of the filesystem in use differs from the operating system default. Predicate method for root directories. Returns true if the pathname consists of consecutive slashes. It doesn't access the filesystem. Returns the dirname and the basename in an Array. Home Core 3. Home Classes Methods.
Parent Object. Pathname Pathname represents the name of a file or directory on the filesystem, but not the file itself. Public Class Methods getwd click to toggle source.
Returns the current working directory as a Pathname. Returns or yields Pathname objects. Provides a case-sensitive comparison operator for pathnames. Predicate method for testing whether a path is absolute. It returns true if the pathname begins with a slash. Returns the last access time for the file. See File. Returns the last component of the path. Returns all the bytes from the file, or the first N if specified. Writes contents to the file, opening it in binary mode.
See FileTest. Returns the change time for the named file the time at which directory information about the file was changed, not the file itself. Deletes the named files, returning the number of names passed as arguments. Raises an exception on any error.
Since the underlying implementation relies on the unlink 2 system call, the type of exception raised depends on its error type see linux. Returns true if the named file is a directory, or a symlink that points at a directory, and false otherwise. Returns true if the named file is executable by the effective user and group id of this process. See eaccess 3. Returns true if the named file is executable by the real user and group id of this process. See access 3. A more complex example which also resolves parent directory is as follows.
Returns the extension the portion of file name in path starting from the last period. If path is a dotfile, or starts with a period, then the starting dot is not dealt with the start of the extension. An empty string will also be returned when the period is the last character in path. If the file argument is a symbolic link, it will resolve the symbolic link and use the file referenced by the link.
Returns true if path matches against pattern. The pattern is not a regular expression; instead it follows rules similar to shell filename globbing. It may contain the following metacharacters:. Matches any file.
Can be restricted by other values in the glob. Matches any one character in set. Behaves like a Regexp union? The same glob pattern and flags are used by Dir::glob. Returns true if the named file exists and the effective group id of the calling process is the owner of the file.
Returns false on Windows. Equivalent to File::chmod , but does not follow symbolic links so it will change the permissions associated with the link, not the file referenced by the link.
Often not available. Equivalent to File::chown , but does not follow symbolic links so it will change the owner associated with the link, not the file referenced by the link. Returns number of files in the argument list. Creates a new name for an existing file using a hard link. Not available on all platforms.
Same as File::stat , but does not follow the last symbolic link. Instead, reports on the link itself. Sets the access and modification times of each named file to the first two arguments. If a file is a symlink, this method acts upon the link itself as opposed to its referent; for the inverse behavior, see File.
Returns the number of file names in the argument list. Returns the modification time for the named file as a Time object.
Opens the file named by filename according to the given mode and returns a new File object. See IO. If a file is being created, permission bits may be given in perm. These mode and permission bits are platform dependent; on Unix systems, see open 2 and chmod 2 man pages for details. The new File object is buffered mode or non-sync mode , unless filename is a tty. With no associated block, File. If the optional code block is given, it will be passed the opened file as an argument and the File object will automatically be closed when the block terminates.
The value of the block will be returned from File. If a file is being created, its initial permissions may be set using the perm parameter. See File. Although this behavior makes require less suitable than load for quick exploratory code loading, it does prevent programs from needlessly reloading the same code again and again, similar to how autoload works once a constant has been loaded. Another interesting property of require is that you can omit the file extension when loading your code.
Thus require ". Though this may seem like a small feature, the reason it exists is that Ruby can load more than just Ruby files. This behavior is another detail that separates require from load , as the latter can work only with explicit file extensions. The main benefit of using require is that it provides the explicit, predictable loading behavior of load with the caching functionality of autoload.
It also feels natural for those who use RubyGems, as the standard way of loading libraries distributed as gems is via the patched version of Kernel require that RubyGems provides. Using require will take you far, but it suffers from a pretty irritating problem—shared by load and autoload —with the way it looks up files.
Each time I referenced files using a relative path in the previous examples, I wrote the path to explicitly reference the current working directory. Ruby 1. So, in our previous example, if we attempted to write require "calendar" instead of require ". Explicitly referencing the current working directory works on both Ruby 1. Unfortunately, it is an antipattern, because it forces us to assume that our code will be run from a particular place on the file system.
One way to solve this problem is to use the same mechanism that the Ruby standard library and RubyGems uses: modify the loadpath. This approach works, and was quite common in Ruby for some time.
Then, people began to get itchy about it, because it is definitely overkill. The latter approach requires less effort from the end user but makes your code ugly. This code will evaluate to different values depending on where you run it from, but in the end, the right path will be produced and things will just work. Predictably, people took efforts to hide this sort of ugliness behind helper functions, and one such function was eventually adopted into Ruby 1.
The files we reference are relative to the file in which the actual calls are made, rather than the folder in which the script was executed in. Of course, it is not a perfect solution. In some cases, it does not work as expected, such as in Rackup files.
The former issue cannot be worked around, but the latter can be. It has the fewest dark corners and pretty much just works. That said, take my advice with a grain of salt. I no longer actively maintain any Ruby 1. But any of those four options seem like at least reasonable ideas.
I would not employ the common but painfully ugly require ". Occasionally, I do use load , particularly in spikes where I want to reload files into an irb session without restarting irb. A possible good reason would be if I were building some sort of script runner, such as what you could find in Rails when it reloads your development environment or in autotest. In the autotest case in particular in which your test files are reloaded each time you make an edit to any of your files in your project, it seems that using load with its obscure second parameter is a good idea.
0コメント