Corrupted Files when running the ActivePerl Linux installer


When I run the installer, it reports that several files are corrupted. I see this error:
This installer package does not have the expected content. Please try to download a fresh copy of ActivePerl from ActiveState's website at If you still have problems please contact us at SupportEmail.

How do I fix this?


---Updated 10/18:
This FAQ applies to ALL ActivePerl Linux tarball installers.
A link to a current version has been specified solely for convenience
There are two possible causes.

1) If you used the command line "tar" to extract the archive, and tar reported this:
"tar: Removing leading / from member names"
the version of tar you have installed is removing leading slashes by default as a security measure. This will break the ActivePerl installer. Delete the extracted folder and run tar with different options.
"tar -zxPf (filename for the ActivePerl installer tarball with extensions.)"

2) If you allowed your browser to extract the tarball, it will have use the Linux Archive Manager. Trash the ActivePerl folder you extracted. Download a fresh copy, and do not open the Download with the Linux Archive Manager.
Go to a Terminal Window, and extract the file on the command line, using GNUtar instead:
You may still hit the leading slash issue if your tar has that default behaviour.

When the Ruby debugger bails out with an obscure error message (Linux 64-bit)


When I try to use the Ruby debugger, on a 64-bit Linux machine, stops after giving this error message:

Error: cannot load such file --

What should I do?


So is a Ruby C-extension that is used by the debugger, and
normally can be completely ignored. It was a bit puzzling why Ruby wasn't
loading this file, as it was clearly present and on Ruby's library load

I got the customer who reported this problem to fire up irb, cd'ed to
the directory containing, and run `require 'trace_nums19'`.
He reported this error message:

irb(main):002:0> require './trace_nums19'
LoadError: cannot open shared object file: No such file or
directory -
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from (irb):2
        from /usr/bin/irb:12:in `<main>'

The customer had /usr/lib/ installed, but not libruby-so.1.9
I see that rvm installs in each directory, and then
creates symbolic links and pointing to it, so the
libruby-so.M-N form looks correct. But this naming is inconsistent -- Python
puts the version numbers before the ".so" extension, while Perl and Ruby
typically put them after.

Anyway, the simple fix was to run

cd /usr/lib
sudo ln -s

Komodo IDE and Right-to-Left (RTL) Languages


Will Komodo work with Farsi, Hebrew or some Asian languages that are read right to left?


Komodo unfortunately does not work with right-to-left languages, as mentioned in our Komodo IDE release notes, due to a limitation in the text editor component.

Why doesn't Ctrl-Shift-U lower-case a selection on Linux


The Code menu gives a keybinding of "Ctrl+Shift+U" for "Make Lowercase", but when I try this, the selection is replaced by the letter "u" and the cursor no longer moves. What's going on?


Some Linux platforms use the Shift-Ctrl-U as an signal to move into an in-place Unicode Input Method Editor (IME), and Komodo can't override that to implement the lowercase-selection command. However this isn't the case on all Linux platforms, and we can't have Komodo determine it at runtime either.

If you're on Unix, you can use the Preferences|Editor|Key Bindings to assign this command to a new key binding; I found [Ctrl K + L] is as memorable as the default key sequence, and it isn't being used.

If you do end up in this IME mode, you can press the Escape key to get out of it.

CGI Debugging: 'No Input File specified'


When I try to debug PHP using CGI Emulation, I get this error:

No input file specified.


This is because your PHP CGI interpreter has been compiled with cgi.force_redirect set to on for security reasons. We can fix this in Komodo by changing this setting in the copy of php.ini that Komodo uses:

- open the php.ini copy that Komodo is using:


- change the setting:

; cgi.force_redirect = 1


cgi.force_redirect = 0

Save the php.ini, then try debugging using CGI Emulation again.