They say here that ICU is used on many platforms. But I can't find what version comes with OS X and Windows. In Linux I suppose a package-manager would tell me.
UPDATE: Changed CLDR to ICU
I don't know whether platforms come bundled with ICU. For sure, Windows does not. Unix-based platforms might. For one, apparently OS X comes bundled with some version of it.
If the platform delivers a full bundle of ICU you can test the version of ICU using the command:
$ uconv -V
Which will print the version. The latest version is 54.1, it looks like this:
uconv v2.1 ICU 54.1
In addition, if your platform has Qt installed, it is possible it has been compiled with ICU support, but this is not a necessity.
If you want to use ICU, you're probably better off shipping it with your product as opposed to rely on what is on someone's system. ICU has a fairly regular update cycle, chances are that pre-installed ICU libraries are out of date.
Completing #Abel's answer, on macOS the complete command to extract the ICU version is:
$(brew --prefix)/opt/icu4c/bin/uconv --version | sed -ne 's/uconv v.* ICU \([0-9][0-9.]*\)/\1/p'
This produces e.g. 72.1 as of today (2022-01-21).
On Ubuntu, uconv is in the PATH if installed, so this is simply:
uconv --version | sed -ne 's/uconv v.* ICU \([0-9][0-9.]*\)/\1/p'
Related
We have an old OLD binary which was built on OLD Solaris OS (pre Solaris 10 version).
I need to rebuild some of its code in same Old Solaris OS.. No one know in which version it was built and no machine details available..
The binary is running on Solaris 10. But for some backward compatibility purpose (believe me.. ) they still wanted it to built on Old Solaris.
is there a way to find in which OS version that binary was build..? (last stupid belief).
Depending on how the binary was built, the command:
mcs -p binary
might give you a good hint.
Otherwise, as Andrew suggested (with optional filtering added):
strings -a binary | egrep -i "solaris|sunos|version|5\."
I’m a mere mortal using Cygwin on Win7 and wanting to develop perl scripts using SOAP::lite. Installation instructions I found at soaplite.com directed me to start with perl –MCPAN –e shell before attempting an > install SOAP::lite
The newb in me didn’t appreciate that my windows user profile has a space character in it and the CPAN set-up seemed to go all horribly wrong around the point where the script was writing make files for local::lib, MYMETA.yml and MYYMETA.json. I got “no such file or directory” messages quoting only the portion of the path that followed the space in my user profile.
$ uname -a
CYGWIN_NT-6.1 UKLHRL00020 2.0.4(0.287/5/3) 2015-06-09 12:22 x86_64 Cygwin
$ cpan --version
Loading internal null logger. Install Log::Log4perl for logging messages
/usr/bin/cpan version 1.61 calling Getopt::Std::getopts (version 1.06 [paranoid]),
running under Perl version 5.14.4.
[Now continuing due to backward compatibility and excessive paranoia.
See ``perldoc Getopt::Std'' about $Getopt::Std::STANDARD_HELP_VERSION.]
Nothing to install!
When I ran perl –MCPAN –e shell for the first time, it did report “Warning: You do not have write permission for Perl library directories.” and I elected for the default option [local::lib] for the approach to be taken.
So what can I do next?
Looking closer at the Cygwin’s setup-x86_64.exe, a search for “cpan” lists eight packages under the perl category for perl-CPAN-* and perl-Parse-CPAN*, which are all set to “Skip”. The package perl-CPANMeta: Perl distribution CPAN-Meta is version 2.150001-1 from cygwin.mirrors.pair.com. Since this is not installed yet, but the installed Perl5 has some knowledge of an old CPAN, I need to know if it is safe to install the latest and will it work with a space in my profile? Do I need to remove the old CPAN, and how?
You probably want to update to the latest version of ExtUtils::MakeMaker, recent versions contain various fixes for paths containing spaces. This should fix these issues.
I have a Perl module that handles localization tasks using the GNU gettext utilities xgettext, msgfmt, msginit, and msgmerge. I got some test failures from a SunOS system which, when I looked into it, seemed to be ancient. For now I am skipping tests when msgfmt and xgettext choke on a simple --version option. But I think it would be better to refuse to install unless a relatively modern version of the GNU Gettext utilities are installed.
So, what's the best way to do that? I'd like to just figure out what's installed and if it supports the options I need, and refuse to install the module if those dependencies are not met. Should I just run gettext --version and refuse to install if it exits with a non-0 value? Or might there be a more canonical solution?
Since "gettext --version" should always return a value on any "contemporary" version (for example, I just tried it on a circa 1997 Redhat ... and it worked!), that should be sufficient.
IMHO...
I am trying to install ruby version manager on a g4 ibook running 10.4 but I receive two error messages right off the bat when I try to run the first command:
$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
bash: line 6: set: errtrace: invalid option name
bash: line 13: conditional binary operator expected
I am new to ruby, rails, and fairly inexperienced with the command line too. I've done a bit of searching and have seen other people having problems installing a specific version of ruby on a powerpc using rvm, but no other examples of someone having a problem installing rvm first of all.
Does this seem like a powerpc issue? Or is there something simple with the command line that I am missing here?
I have also searched on these specific error messages but haven't found any solutions yet. Oh and I should also add that I have xcode installed and I also installed macports because I thought that might help...but it hasn't.
The most probable cause of the error you're getting is your bash version is far too old to be used with any relatively new RVM version. Also, the likelihood of you being able to easily compile rubies on a G4 now is very low. You'll likely end up needing to compile many tools and libraries from source which you'll have to do from the command-line. Finding the right combination of library versions that both support your arch and are still available for download might not be as easy as it sounds. Much of the ruby compilation on OS X depends on libraries that come with Xcode. So, you might hit a wall there too with rubies now requiring newer libraries that can be provided with a version of Xcode that can be installed on your system.
You can try upgrading your bash version and/or use a much older version of RVM, although, I don't remember RVM ever working on 10.4. Or, you can try to compile everything from source, including Ruby. You'll might be able to get Ruby 1.8.6, maybe 1.8.7 working but anything higher is very unlikely.
Good luck =/
I'm have Perl 5.8 installed on all of our servers and wanted to use the DBI and DBD::Oracle modules to access our databases. My main concern is with the newer versions of perl the DBI and DBD modules will stop working with 5.8. Then I'd have to upgrade every server to the newest perl version.
My question is as perl itself becomes later versions and modules are developed for them will they still be backwards compatible? "CPAN does not carry all ancient releases and patchlevels of Perl", if I create documentation saying run "cpan -i DBI" if the newest version of DBI will not function with 5.8?
There is no guarantee.
In general, you want to use the same versions of the modules on all your systems. If you use different versions then you will have different bugs and features available on different servers.
I'd suggest creating Debs / RPMS / etc for the ones you are going to use and then run a package repository that all your servers share.
Not absolutely, but in general perl is pretty gentle about breaking code, with not many breaking changes, and long deprecation cycles on the ones that do happen. A pretty hefty portion of the code that was uploaded to CPAN in 1999 will run without modification in perl 5.14.
Since perl 5.12, the perl release cycle has become shorter, and the deprecation periods have also become shorter, which is cause for concern, but at the same time the concept of feature versioning has gained currency. The idea is that code may declare the version of perl that it's targeting with use VERSION (e.g. use 5.16.0), and any code that doesn't declare a version is assumed to be targeting approximately 5.10. When code that targets an older perl version is run on a newer perl version, newer features that might cause compatibility issues (e.g. new keywords) are disabled, and old misfeatures may be re-enabled in the name of compatibility. This isn't an absolute guarantee, but it will be adhered to as much as practical.
More information about back-compatibility and deprecation is in perlpolicy.
In general, no. There are a lot of great new features in recent releases of Perl (smart match operator, the // operator, for two one example) that are not backwards compatible. Many authors will decide to take advantage of these features rather than keep their modules compatible with older versions of Perl.
Check the CPAN Tester's Matrix of a module, including the link about the max version that passes all of the distribution's tests, to get an idea of what versions of Perl are compatible with each version of a module.
cpan -i Some::Module will indeed attempt to install the latest version of the module Some::Module, but with a little research, it can be used to install older versions too. You need to find or guess the author of an older version and provide the path to the distribution on the CPAN mirror servers. For example,
cpan -i J/JF/JFRIEDL/Yahoo-Search-1.9.12.tar.gz
cpan -i A/AS/ASG/List-Gen-0.80.tar.gz
CPAN authors may delete their older distributions from CPAN. But even then, the distribution is available at the BackPAN if you're willing to download, unpack, and build the distribution yourself.