In addition to String values, $LOAD_PATH can also take objects that
respond_to the `to_path` method, like Pathname objects. So `irb` should
be able to handle those objects too.
And if $LOAD_PATH contains objects that can't be converted into String,
`irb` should simply ignore it.
b2f562176b
The warning against `-undefined dynamic_lookup` is just a warning yet,
and many gems seem to pay no attention to warnings. Until it fails
actually, keep it as a migration path, except for standard extension
libraries and bundled extension gems.
Also add --script option to turn the option back on.
Previously there wasn't a way to get an interactive IRB session
and access arguments provided on the command line.
Additionally, handle `-` as script as stdin. In Unix-like tools, `-`
means to take standard input instead of a file. This doesn't
result in exactly the same output for:
```
echo 'p ARGV' > args.rb; irb args.rb a b c
```
and
```
echo 'p ARGV' | irb - a b c
```
Due to how irb handles whether stdin is a tty.
However, this change allows use of `-` as a argument, instead of
giving an unrecognized switch error. This required some small
changes to context.rb (to handle `-` as standard input) and
input-method.rb (to have FileInputMethod accept IO arguments in
addition to strings).
Implements [Feature #15371]
4192683ba2
When extracting files from the tarball, a mode is retrieved from
the header. Occasionally you'll encounter a gem that was packaged
on a system whose permission bits result in a value that is larger
than the value that File.chmod will allow (anything >= 2^16). In
that case the extraction fails with a RangeError, which is pretty
esoteric.
If you extract the tarball with the tar and gunzip utilities, the
file permissions end up being just the bottom 16 bits masked off
from the original value. I've mirrored that behavior here. Per the
tar spec:
> Modes which are not supported by the operating system restoring
> files from the archive will be ignored.
I think that basically means what I've done here.
---
This commit also changes the behavior very slightly with regard to
when the chmod is called. Previously it was called while the file
descriptor was still open, but after the write call.
When write flushes, the file permissions are changed to the mode
value from the File.open call, undoing the changes made by
FileUtils.chmod. CRuby appears to flush the buffer after the
chmod call, whereas TruffleRuby flushes before the chmod call.
So the file permissions can change depending on implementation.
Both implementations end up getting the correct file permissions
for the bottom 9 bits (user, group, world), but differ with
regard to the sticky bit in the next 3.
To get consistent behavior, this commit changes it to close the
file descriptor before attempting to chmod anything, which makes
it consistent because the write flushes in both cases.
22ce076e99
If history file didn't exist when irb was started, @loaded_history_mtime
would be nil. However, if the history file didn't exist before, but it
exists when saving history, that means the history file was modified,
and we should handle it the same way as we handle the other case where
the history file was modified.
Fixes#3888d277aafcb
I want to use more complicated macros with MJIT. For example:
```
# define SHAPE_MASK (((unsigned int)1 << SHAPE_BITS) - 1)
```
This commit adds a simple recursive descent parser that produces an AST
and a small visitor that converts the AST to Ruby.
I'm thinking about Ruby builtin code instead of doing this.
It'll be hopefully more portable and easier because the same C code could
handle both 32bit and 64bit.
f7cf641469 broke spec/bundler/install/gems/resolving_spec.rb:356.
This line seems to impact that test, so I slightly modified the
implementation for that spec's case.
After recent musl support was added, Bundler started hanging in musl
platforms. I identified the issue where valid candidates were being
filtered out because their platform was specified as a string, and thus
`Gem::Platform.match_spec?` which under the hood ends up calling
`Gem::Platform#===` would return `nil`, because it does not support
comparing platforms to strings.
In particular, `Bundler::EndpointSpecification`'s platform coming from
the API was not instantiated as a `Gem::Platform`, hence the issue.
Also, this spec surfaced another issue where a bug corrected in
`Gem::Platform#match_platforms` had not been yet backported to Bundler.
So this commit also backports that to get the spec green across RubyGems
versions.
Finally, the fix in `Bundler::EndpointSpecification` made a realworld
spec start failing. This spec was faking out `rails-4.2.7.1` requirement
on Bundler in the `Gemfile.lock` file to be `>= 1.17, < 3` when the real
requirement is `>= 1.17, < 2`. Due to the bug in
`Bundler::EndpointSpecification`, the real requirement provided by the
compact index API (recorded with VCR) was being ignored, and the
`Gemfile.lock` fake requirement was being used, which made the spec
pass. This is all expected, and to fix the issue I changed the spec to
be really realworld and don't fake any Bundler requirements.
faf4ef46bc
The "dumb" terminal is considered only on MSys tty now. However, the
`TERM` feature has been used on many Unix-like systems for decades,
not MSys specific.
53fd51ab62
RDoc is implemented as soft dependency in IRB. See how the rdoc is required in
the files. I reverted the commit below.
```
$ grep -ril rdoc lib/
lib/irb/cmd/help.rb
lib/irb/completion.rb
lib/irb/easter-egg.rb
lib/irb/input-method.rb
```
---
Revert "Remove `require` in signal handler to avoid ThreadError"
This reverts commit 5f749c613c.
b24852058f
Recently a changed was introduced to update the resolver platforms after
it has been created, in order to remove the "ruby" platform from it if
it's to be removed from the lockfile. However, it did not update the
`@resolving_only_for_ruby` instance variable in that case, so the
resolver was not properly doing the right thing anymore.
To fix this, I tweaked the code to restore not changing resolver
platforms after the resolver has been instantiated.
8fbc30a1d0
This has been introduced in 026700499d,
but it seems that this is just be mistake, otherwise the later handling
of `LoadError` would not be needed.
54c8df06ff
... instead of any StandardError.
To behave like the standard `rm` command, it should only ignore
exceptions about not existing files, not every exception. This should
make debugging some errors easier, because the expectation is that `rm
-rf` will succeed if and only if, all given files (previously existent
or not) are removed. However, due to this exception swallowing, this is
not always the case.
From the `rm` man page
> COMPATIBILITY
>
> The rm utility differs from historical implementations in that the -f
> option only masks attempts to remove non-existent files instead of
> masking a large variety of errors.
fa65d676ec
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
The ensure in postorder_traverse was added for [Bug #6756].
The intention was to try to delete the parent directory if it failed to
get the children. (It may be possible to delete the directory if it is
empty.)
However, the ensure region rescue'ed not only "failure to get children"
but also "failure to delete each child". Thus, the following raised
Errno::ENOTEMPTY, but we expect it to raise Errno::EACCES.
```
$ mkdir foo
$ touch foo/bar
$ chmod 555 foo
$ ruby -rfileutils -e 'FileUtils.rm_rf("foo")'
```
This changeset narrows the ensure region so that it rescues only
"failure to get children".
ec5d3b84ea
