I am using the build in Codeigniter Agent detection library and that outputs
the browser version. The only problem is that it outputs the complete version number.
For example this for Chrome:
16.0.912.77
I only need this:
16
How can I trim away everything after 16? It must work for other browser versions too.
Like 7.44.3.
Thankful for all help!
What about this:
$version = '16.0.912.77';
$shortVersion = explode('.', $version);
$shortVersion = $shortVersion[0];
echo $shortVersion; // will output <16>
Related
My question is about use of '?' with wkhtmltopdf
Using StackOverflow advice, I have wkhtmltopdf working as invoked from a
php webpage...for example this works as expected:
$exec_string = "xvfb-run -a -s "."\"-screen 0, 1024x768x24 \""."
wkhtmltopdf http://example.com temp.pdf";
exec($exec_string);
However, if I add to the URL like this:
http://example.com/?page=clients
wkhtmltopdf ignores the page=clients and produces a pdf identical to the above result. I even tried surrounding with " as
...\"http://example.com/?page=clients \"...
but still no good.
How can I force wkhtmltopdf to pickup the the ?page=clients piece?
I've discovered my problem is more complicated than simply wkhtmltopdf not recognizing ?page=clients.
The website that the page belongs to does 'security' checks prior to displaying a page like this. An experiment done outside this framework shows me that wkhtmltopdf does indeed pickup the page=clients specification.
I want to use wkhtmltopdf to render both pages I control (in which case I can set the window.status when done rendering) and (occasionally) pages I don't control. According to this thread on the mailing list I should be able to set --window-status to some value, and --javascript-delay as well, and rendering starts as soon as either of these conditions is met. That's not my experience; the command wkhtmltopdf --javascript-delay 10000 --window-status imdone http://www.google.com/ /tmp/google.pdf waits forever (version 0.12.3, both on OSX and linux). How can I get the behaviour as described on the mailinglist?
One workaround is to use the --run-script tag to set the window.status after some time manually -- this works both on the version that uses the patched and that that uses the unpatched QT. Note however that --run-script seems to have a small bug in escaping its parameter. Therefore the following line will give you the behaviour requested:
wkhtmltopdf --window-status imdone --run-script \
'window.setTimeout(function(){window.status="imdone";},1000);' \
http://google.com/ /tmp/google.pdf
Note that because of aforementioned bug, it doesn't work if one puts spaces in the --run-script argument, hence the following will not work
wkhtmltopdf --window-status imdone --run-script \
'window.setTimeout(function (){window.status = "imdone";}, 1000);' \
http://google.com/ /tmp/google.pdf
I'm upgrading a mac workstation that we use for some automated data processing. In this processing we call a couple of bash scripts. The work station is currently at 10.7.x and we want to upgrade it to Mavericks.
One of the things I need to determine is if upgrading will break the bash scripts.
Most of the commands are regular /usr/bin commands:
perl
awk
sort
comm
join
uniq
sed
But one in particular is something that was intensionally installed (I thought it was installed via macports, but I don't see it in the installed list).
gjoin
Is there a good way of determining if these commands change in any substantial way between versions before I actually upgrade the workstation?
None of those are "/usr/bin commands". They are binaries that exist on the system. They have nothing to do with your shell, as such.
Most, if not all, of those commands will report their version should you ask them (with --version or similar).
To determine whether things might possibly break you get to find out what has changed between the versions in question and to know whether that matters you need to know what the scripts that call them do and what functionality, from those binaries/languages, they use. That being said I think it very unlikely that updates to those commands will cause your scripts trouble unless your scripts depend on broken behaviour in the given tool or depend on explicit error (or other) messages from the tools for their operation.
Edit: As Pumbaa80 points out in his comment on the OP the only real way to know for sure whether the scripts will work or not is to try them and see. Though obviously testing of non-trivial scripts is certainly complicated and can be very difficult (if not all-but practically impossible depending on the task and script).
By the way...
Amongst the binaries/commands you list, Perl is the odd one out because that typically cannot be considered to have a single version, since it can have a load of additional installed modules which themselves can all be different versions. You may find it useful to run the following on your existing OSX 10.7 to find which modules are installed there so you can grab and install the same ones on Mavericks.
perl -MExtUtils::Installed -MData::Dumper -e '$inst=ExtUtils::Installed->new();print Dumper($inst->modules());'
For example, mine gives this:
$VAR1 = 'Bundle::NetSNMP';
$VAR2 = 'CPAN';
$VAR3 = 'Color::Similarity';
$VAR4 = 'Crypt::RC4';
$VAR5 = 'Devel::NYTProf';
$VAR6 = 'Digest::Perl::MD5';
$VAR7 = 'File::HomeDir';
$VAR8 = 'Graphics::ColorNames';
$VAR9 = 'Graphics::ColorObject';
$VAR10 = 'Image::Magick';
$VAR11 = 'JSON';
$VAR12 = 'JSON::Any';
$VAR13 = 'Mac::SystemDirectory';
$VAR14 = 'Mozilla::CA';
$VAR15 = 'OLE::Storage_Lite';
$VAR16 = 'Perl';
$VAR17 = 'Spreadsheet::ParseExcel';
$VAR18 = 'Spreadsheet::XLSX';
$VAR19 = 'Test::Without::Module';
$VAR20 = 'mod_perl2';
I work on Mac OS X 10.7.3 with R version 2.14.0 (2011-10-31). My ~/.Rprofile is
options(repos=c(CRAN="http://cran.ch.r-project.org",
BioC="http://www.bioconductor.org",
Omegahat="http://www.omegahat.org/R"),
pdfviewer=path.expand("~/R/misc/shell_scripts/skim"),
browser="mybrowser")
where mybrowser is a file in /bin/ which contains open -a "/Applications/Google Chrome.app". When I open R and type help.start(), all I obtain is that Chrome becomes active, but no real output from help.start(). How can I properly set up browser in options so that help.start() works as expected?
I originally just had browser="Chrome", but R couldn't find the browser. I tried several kinds of things to solve this (e.g., browser="/Applications/Google Chrome.app" [and various variants to escape the blank]), but none worked. I guess that's because sh /Applications/Google\ Chrome.app just does not work. On the Mac, applications are opened via open -a ..., that's why I created mybrowser. That finally opened the browser, but I couldn't figure out how to get help.start to work properly.
Create a Renviron file in your home (i.e ~/.Renviron) and add this line.
R_BROWSER=google-chrome
I'm not sure about "chrome" part, i use conkeror and my setup is :
R_BROWSER=conkeror
But this should do the tricks
In the meantime, Hans-Joerg Bibiko helped out: the solution is to set browser to browser="/usr/bin/open -a 'Google Chrome'"
If you look in utils:::print.help_files_with_topic (the function that actually issues the call to browseURL()), there is this really annoying line:
if (.Platform$GUI == "AQUA" && type == "html")
browser <- get("aqua.browser", envir = as.environment("tools:RGUI"))
And since .Platform$GUI == "AQUA" on OSX, this means that you have to do some trickery to browse help files in your favorite browser. Hence, in my .Rprofile (located here path.expand('~/.Rprofile'), of course), I included these lines.
options(help_type='html')
options(browser="/usr/bin/open -a '/applications/Google Chrome.app'")
p <- .Platform
p$GUI = 'unknown'
unlockBinding('.Platform', as.environment('package:base'))
assign('.Platform', p , envir=as.environment('package:base'))
lockBinding('.Platform', as.environment('package:base'))
rm(p)
So far it doesn't seem to have any effect other than enabling use of an alternate browser, but you may want to read the section labeled "Aqua" in ?.Profile if you're worried about messing around with base.
I need to get the current encoding according to the system local settings. I'm looking for such function working this way:
my $sysEncoding = getSystemEncoding();
#and now $sysEncoding equals e.g. 'windows-1250'
I looked everywhere on the internet. I've found just the module PerlIO::locale. But I thing that the system encoding should be recognized easier without additional modules.
Encode::Locale provides the means to handle this.
use Win32::API;
if (Win32::API->Import('kernel32', 'int GetACP()')) {
$enc = GetACP();
print "Current local encoding is '$enc'\n";
}
Thanks for hint to Ikegami.