prob with exec, exiftool and one photo

[Une Bévue]

Hey all,

I have a folder with photos :

$ ls -al '/Users/yt/Sites/tests/Flipping_image/photos/'
total 4848
drwxr-xr-x 10 yt staff 340B 13 déc 09:46 .
drwxr-xr-x 10 yt staff 340B 13 déc 07:48 ..
-rw-r--r-- 1 yt staff 1,1M 12 déc 10:01 20161202_085945.jpg
-rw-r--r-- 1 yt staff 66K 13 déc 08:10 Cirques.jpg
-rw-r--r-- 1 yt staff 662K 13 déc 08:27 Cirques.png
-rw-r--r-- 1 yt staff 541K 6 déc 13:43 IMG_3130.JPG

those photos have the same user and group and also the same rights
'-rw-r--r--'.

i need to read exif infos from those files using the php script :

$EXIFTOOL = '/usr/local/bin/exiftool';
$cmd = "$EXIFTOOL " . $data['PATH'];
exec($cmd, $Infos, $ExitStatus);
foreach($Infos as $line) {
$fields = explode(' : ', $line, 2 );
if(count($fields) == 2) {
$data[rtrim($fields[0])] = $fields[1];
}
}
$data['ExitStatus'] = $ExitStatus;

for 3 of those photos :
Cirques.jpg
Cirques.png
IMG_3130.JPG

i get back the good exif infos, like :
{
"ExifTool Version Number": "10.20",
"File Name": "IMG_3130.JPG",
"Directory": "\/Users\/yt\/Sites\/tests\/Flipping_image\/photos",
"File Size": "541 kB",
[...]
"Hyperfocal Distance": "1.82 m",
"Light Value": "4.0",
"ExitStatus": 0
}

($data is send thru json_encode)

however for the photo '20161202_085945.jpg' the php script returns
nothing even no error althought I'm able, on terminal to retrieve those
datas :
$ /usr/local/bin/exiftool
/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg
ExifTool Version Number : 10.20
File Name : 20161202_085945.jpg
Directory :
/Users/yt/Sites/tests/Flipping_image/photos
File Size : 1128 kB
File Modification Date/Time : 2016:12:12 10:01:18+01:00

[...]

Field Of View : 60.3 deg
Focal Length : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance : 1.47 m


the only difference I see is the weight of this photo (1,1MB, the other
being less than 0.7MB)

then i need some light in order to find what is broken here.

best,

YT

[Une Bévue]

I forgot to mention I'm working on macOS Sierra with PHP 5.6.25.

[Christoph M. Becker]

On 13.12.2016 at 17:14, Une Bévue wrote:

> i need to read exif infos from those files using the php script :
>

> […]

>
> however for the photo '20161202_085945.jpg' the php script returns
> nothing even no error althought I'm able, on terminal to retrieve those
> datas :
> $ /usr/local/bin/exiftool
> /Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg
> ExifTool Version Number : 10.20
> File Name : 20161202_085945.jpg
> Directory :
> /Users/yt/Sites/tests/Flipping_image/photos
> File Size : 1128 kB
> File Modification Date/Time : 2016:12:12 10:01:18+01:00
>
> [...]
>
> Field Of View : 60.3 deg
> Focal Length : 3.7 mm (35 mm equivalent: 31.0 mm)
> Hyperfocal Distance : 1.47 m
>
>
> the only difference I see is the weight of this photo (1,1MB, the other
> being less than 0.7MB)
>
> then i need some light in order to find what is broken here.

Due to security fixes in PHP 5.6.24 and 7.0.9 some of the Exif
funtionality has been broken. So, which PHP version do you use?

--
Christoph M. Becker

[R.Wieser]

Une,

> the only difference I see is the weight of this photo (1,1MB,
> the other being less than 0.7MB)

Another difference is that the other three are compliant to the old 8.3 DOS
format, while the latter has a much longer filename.

Try renaming it to something short and see what happens.

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewus...@fai.invalid> schreef in berichtnieuws
o2p6o9$pgl$1...@shakotay.alphanet.ch...

[Une Bévue]

Le 13/12/2016 à 17:28, Christoph M. Becker a écrit :
> Due to security fixes in PHP 5.6.24 and 7.0.9 some of the Exif
> funtionality has been broken. So, which PHP version do you use?

PHP Version 5.6.25

Butnotice I'm not using an Exif functionnality bultin PHP but rather the
commandline exiftool.

[Une Bévue]

Le 13/12/2016 à 18:03, R.Wieser a écrit :
> Another difference is that the other three are compliant to the old 8.3 DOS
> format, while the latter has a much longer filename.

OK, but I'm using macOS Sierra...

> Try renaming it to something short and see what happens.

Anyway, I renamed it 'glasgow.jpg', no result with php, and again using
terminal I got it :

$ exiftool /Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg
ExifTool Version Number : 10.20
File Name : glasgow.jpg

Directory :
/Users/yt/Sites/tests/Flipping_image/photos
File Size : 1128 kB
File Modification Date/Time : 2016:12:12 10:01:18+01:00

[...]

Circle Of Confusion : 0.004 mm

[J.O. Aho]

On 12/13/2016 05:14 PM, Une Bévue wrote:

> i need to read exif infos from those files using the php script :
>
> $EXIFTOOL = '/usr/local/bin/exiftool';
> $cmd = "$EXIFTOOL " . $data['PATH'];
> exec($cmd, $Infos, $ExitStatus);
> foreach($Infos as $line) {
> $fields = explode(' : ', $line, 2 );
> if(count($fields) == 2) {
> $data[rtrim($fields[0])] = $fields[1];
> }
> }
> $data['ExitStatus'] = $ExitStatus;
>
> for 3 of those photos :
> Cirques.jpg
> Cirques.png
> IMG_3130.JPG
>
> i get back the good exif infos, like :
> {
> "ExifTool Version Number": "10.20",
> "File Name": "IMG_3130.JPG",
> "Directory": "\/Users\/yt\/Sites\/tests\/Flipping_image\/photos",
> "File Size": "541 kB",
> [...]
> "Hyperfocal Distance": "1.82 m",
> "Light Value": "4.0",
> "ExitStatus": 0
> }
>

> however for the photo '20161202_085945.jpg' the php script returns
> nothing even no error

What's the exit status code?

Have you verified that the path is correct? Is it a full path or a
relative path (in this case it may not be relative to the script
executed first)?


If your script takes all the files in the directory, but always missing
one file, then your outer loop has issues, as you haven't provided how
you get your $data in the first place, it's just a guessing game for us
who ain't mind readers.


--

//Aho

[Christoph M. Becker]

I was so fixated on the ext/exif issues that I didn't fully read your
post. Sorry for the noise!

--
Christoph M. Becker

[Une Bévue]

Le 13/12/2016 à 23:42, J.O. Aho a écrit :
> What's the exit status code?
>
> Have you verified that the path is correct? Is it a full path or a
> relative path (in this case it may not be relative to the script
> executed first)?

full PATH

>
> If your script takes all the files in the directory, but always missing
> one file, then your outer loop has issues, as you haven't provided how
> you get your $data in the first place, it's just a guessing game for us
> who ain't mind readers.

no the script is activated by :
http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg

and the whole script is :

<?php
$EXIFTOOL = "/usr/local/bin/exiftool";
$SITES = "/Users/yt/Sites";
$data = array();
if(isset($_GET['URL'])) {
$data['URL'] = $_GET['URL'];
$data['PATH'] = $SITES . $_GET['URL'];
}
if(isset($_GET['PATH'])) {
$data['URL'] = explode($SITES, $_GET['PATH'], 2 )[1];
$data['PATH'] = $_GET['PATH'];
}
header('Content-Type: application/javascript');
date_default_timezone_set('Europe/Paris');
setlocale(LC_CTYPE, 'fr_FR');
error_reporting(E_ALL);

function exifTool() {
global $EXIFTOOL;
global $data;

$cmd = "$EXIFTOOL " . $data['PATH'];
exec($cmd, $Infos, $ExitStatus);
foreach($Infos as $line) {
$fields = explode(' : ', $line, 2 );
if(count($fields) == 2) {
$data[rtrim($fields[0])] = $fields[1];
}
}
$data['ExitStatus'] = $ExitStatus;

return $data;
}
echo json_encode(exifTool());
?>

the script is not missing one file. even if I hardcode the path within
the script has for example :
$data['PATH'] = '/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg';

i get absolutely nothing. no errors.

[Une Bévue]

from command line, using :
exiftool -s
'/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'

i saw a faulty encoding line :
Comment : File written by Adobe Photoshop� 5.0
looks here_______________________________________________________^_____

then i write to the file :

$ exiftool -s -Comment=''
'/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
1 image files updated

afterwards I'm able to read other infos, using php.

I don't know this comment tag speaking about photoshop, because this
photo comes from a Samsung SM-N7505 phone.

The photo, by itself didn't be open by Photoshop rather send by email...

[Thomas 'PointedEars' Lahn]

Une Bévue wrote:

> Le 13/12/2016 à 23:42, J.O. Aho a écrit :
>> What's the exit status code?
>>
>> Have you verified that the path is correct? Is it a full path or a
>> relative path (in this case it may not be relative to the script
>> executed first)?
>
> full PATH
>
>> If your script takes all the files in the directory, but always missing
>> one file, then your outer loop has issues, as you haven't provided how
>> you get your $data in the first place, it's just a guessing game for us
>> who ain't mind readers.
>
> no the script is activated by :
> http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg

You are an obnoxious, anti-social pseudonymous address munger who does not
deserve this piece of advice. But to prevent you from harming others in
your blissful ignorance, and as a warning to others, I am making an
exception and reply:

You *really* do NOT want to do that. The least you want to do here is
calling escapeshellarg($_GET['PATH']) before you pass it to exec(), so that
an attacker cannot execute *arbitrary code* on that box (see below for an
example of that).

But even then allowing *anyone* to access *any* file on that box poses a
great security risk. You must realize that as by your code any information
output by exiftool(1) is contained in the JSON HTTP response, an attacker
can determine which files are on that box, what is the file size, the file
modification and access times, the file permissions, and for which processor
architecture have binaries been compiled. Because exiftool(1) is much more
than just a tool to read EXIF (image) metadata.

Fasten your seatbelt and try

http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/bin/sh

I can debug this manually, and make a good prediction as to what you will
get:

> and the whole script is :
>
> <?php
> $EXIFTOOL = "/usr/local/bin/exiftool";
> $SITES = "/Users/yt/Sites";
> $data = array();

processed

> if(isset($_GET['URL'])) {

false

> $data['URL'] = $_GET['URL'];
> $data['PATH'] = $SITES . $_GET['URL'];
> }

ignored

> if(isset($_GET['PATH'])) {

true

> $data['URL'] = explode($SITES, $_GET['PATH'], 2 )[1];

irrelevant

> $data['PATH'] = $_GET['PATH'];

$data['PATH'] = '/bin/sh';

> }
> header('Content-Type: application/javascript');

That is the *wrong* MIME media type for a JSON response. JSON is a data
format, not executable source code.

<http://json.org/>
<http://fr.wikipedia.org/wiki/JSON>

> date_default_timezone_set('Europe/Paris');
> setlocale(LC_CTYPE, 'fr_FR');
> error_reporting(E_ALL);
>
> function exifTool() {
> global $EXIFTOOL;
> global $data;
> $cmd = "$EXIFTOOL " . $data['PATH'];

$cmd = "/usr/local/bin/exiftool /bin/sh";

> exec($cmd, $Infos, $ExitStatus);

exec("/usr/local/bin/exiftool /bin/sh", $Infos, $ExitStatus);

Imagine what would have happened here if I had accessed

http://mbp.local/tests/…/php/exiftool-json.php?PATH=%2F%3Brm%20-rf%20%2F

(Just IMAGINE; DO NOT TRY this [at least not without changing “exec” to
“echo”]!)

> foreach($Infos as $line) {
> $fields = explode(' : ', $line, 2 );
> if(count($fields) == 2) {

AFAICS there will always be two fields with exiftool(1).

> $data[rtrim($fields[0])] = $fields[1];
> }
> }
>
> $data['ExitStatus'] = $ExitStatus;

$data = [
'URL' => 'something irrelevant',
'PATH' => '/bin/sh',
'ExifTool Version Number ' => '10.25',
'File Name ' => 'sh',
'Directory ' => '/bin',
'File Size ' => '110 kB',
'File Modification Date/Time ' => '2016:07:05 23:59:04+02:00',
'File Access Date/Time ' => '2016:12:14 10:44:49+01:00',
'File Inode Change Date/Time ' => '2016:07:10 17:50:26+02:00',
'File Permissions ' => 'rwxr-xr-x',
'File Type ' => 'ELF shared library',
'File Type Extension ' => 'so',
'MIME Type ' => 'application/octet-stream',
'CPU Architecture ' => '64 bit',
'CPU Byte Order ' => 'Little endian',
'Object File Type ' => 'Shared object file',
'CPU Type ' => 'AMD x86-64',
'ExitStatus' => 0
];

or similar.

> return $data;
> }
> echo json_encode(exifTool());
> ?>

Omit the last line: <http://www.php-fig.org/psr/psr-2/#2-2-files>

> the script is not missing one file. even if I hardcode the path within
> the script has for example :
> $data['PATH'] = '/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg';
>
> i get absolutely nothing. no errors.

There may be no error messages, but certainly there is an _$ExitStatus_ (as
your fellow anti-social address munger, “J.O. Aho”, said).

Also, $data is only filled if there are exactly two fields. Maybe that is
the problem – in addition to the many other problems with this code.

--
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Une Bévue wrote:

> from command line, using :
> exiftool -s
> '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
>
> i saw a faulty encoding line :
> Comment : File written by Adobe Photoshop� 5.0
> looks here_______________________________________________________^_____

That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or the
“™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used the
correct locale encoding to decode it.

But as you can see from my other follow-up, you have much bigger problems to
solve than "faulty encoding".

[Une Bévue]

Le 14/12/2016 à 17:37, Thomas 'PointedEars' Lahn a écrit :
>> }
>> header('Content-Type: application/javascript');
> That is the *wrong* MIME media type for a JSON response. JSON is a data
> format, not executable source code.

U're right ! according to :
<http://www.ietf.org/rfc/rfc4627.txt>

i changed that to :
header('Content-Type: application/json');

for the security issue, i don't take care because this page in only a
***local*** test.

[Une Bévue]

Le 14/12/2016 à 17:43, Thomas 'PointedEars' Lahn a écrit :
> That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or the
> “™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used the
> correct locale encoding to decode it.

my locale encoding is "fr_FR.UTF-8".

I don't want to change it for Photoshop ;-)

I think if "Ⓡ” is the correct glyph, I would have seen it on terminal :
.-[y...@mbp.local:~]-[16-12-14 18:20:35]
'->$ set toto ®
.-[y...@mbp.local:~]-[16-12-14 18:20:35]
'->$ echo $toto
®

then the metadatas for this photo isn't UTF-8 encoded ?
only US-ASCII is correct.

[R.Wieser]

Thomas,

> and *you* have not used the correct locale encoding to decode it.

Thats bull, and you know it. It does not need to be "decoded", it needs to
be *extracted", and nothing more.

The only place where that locale decoding is needed is when it needs to be
*displayed*. Nowhere else.


Une, there *might* be a possibility that PHP for some reason does not want
to store unicode and therefore returns an empty result.

J.O. did a good suggestion: Check which error is returned. It's provided
especially for you as the programmer so you have an easier task to home-in
on the cause of the problem.

Also, do not let "pointed ears" here scare you. He's just like that. He
tries to sound as if he's either some internet cop or otherwise allowed to
make demands, but he's harmless.

> You are an obnoxious, anti-social pseudonymous address munger
> who does not deserve this piece of advice

And as always you are the hypocrite, demanding stuff like other people must
use "true names" -- and even telling them where exactly in the message they
should put it -- while violating it yourself with impunity. :-)

Regards,
Rudy Wieser



-- Origional message:

Thomas 'PointedEars' Lahn <Point...@web.de> schreef in berichtnieuws
3256428.M...@PointedEars.de...

> Une Bévue wrote:
>
> > from command line, using :
> > exiftool -s
> > '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
> >
> > i saw a faulty encoding line :

> > Comment : File written by Adobe Photoshop? 5.0
> > looks here_______________________________________________________^_____
>
> That is not faulty encoding; the "?" ("R") for "registered trademark" or
the
> "T" ("(tm)") for "trademark" *belongs there*, and *you* have not used the

[Thomas 'PointedEars' Lahn]

R.Wieser wrote:

> Thomas,

Don’t you "Thomas" me, _R._Wieser. You have yet to earn that privilege.

>> and *you* have not used the correct locale encoding to decode it.
>
> Thats bull, and you know it. It does not need to be "decoded", it needs
> to be *extracted", and nothing more.

Utter nonsense.

> The only place where that locale decoding is needed is when it needs to be
> *displayed*. Nowhere else.

Not displayed, but output. And, if you cared to read, they are using the
output of an external program.

> Une, there *might* be a possibility that PHP for some reason does not want
> to store unicode and therefore returns an empty result.

And Santa Claus comes down the chimney.

>> You are an obnoxious, anti-social pseudonymous address munger
>> who does not deserve this piece of advice
>
> And as always you are the hypocrite, demanding stuff like other people
> must use "true names" -- and even telling them where exactly in the
> message they should put it -- while violating it yourself with impunity.

I would have killfiled you for this if that were not done automatically
already because of your anti-social address munging on top of your anti-
social denying to post with your real name. FOAD.

[Thomas 'PointedEars' Lahn]

Une Bévue wrote:

> Le 14/12/2016 à 17:43, Thomas 'PointedEars' Lahn a écrit :
>> That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or
>> the “™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used
>> the correct locale encoding to decode it.
>
> my locale encoding is "fr_FR.UTF-8".
>
> I don't want to change it for Photoshop ;-)

You could change it temporarily when executing exiftool(1).

But you really need to fix the gaping security leaks in your code first.

When you have done that, you need to post with an e-mail address and a real
name before I consider reading to your postings again. I can only give you
that much leeway.

> then the metadatas for this photo isn't UTF-8 encoded ?

Very likely.

> only US-ASCII is correct.

How did you get that idea?

[Eli the Bearded]

In comp.lang.php, Une Bévue <unbewus...@fai.invalid> wrote:
> from command line, using :
> exiftool -s
> '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
>
> i saw a faulty encoding line :
> Comment : File written by Adobe Photoshop� 5.0
> looks here_______________________________________________________^_____

Not-so-much faulty as software that doesn't understand character set
encodings. JPEG comments are a 32,767 octet block of whatever randomness
you want to put in there. There is no way to indicate what encoding or
set of characters are represented. Adobe is probably just using
something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
like Windows-1250 or Windows-1252.

The JPEG file format dates back to the bad old days of "ASCII is good
enough for everyone (but we'll grudgingly allow EBCIDIC, too)".

http://www.unicode.org/history/publicationdates.html
1.0.0 1991 October

http://fileformats.archiveteam.org/wiki/JFIF
JFIF 1.00 (undated)
JFIF 1.01 (1991-12-10) may have changed the subsampling
position to centered.

(JFIF is JPEG File Interchange Format; that was the first standardized
way to store JPEG compressed data; now JPEG could be JFIF or Exif, which
is a modified JFIF.)

Elijah
------
(would recommend ignoring pointedly-rude pointedears)

[Une Bévue]

Le 14/12/2016 à 19:01, R.Wieser a écrit :
> Une, there *might* be a possibility that PHP for some reason does not want
> to store unicode and therefore returns an empty result.
>
> J.O. did a good suggestion: Check which error is returned.

That's true, however, with that Trademark glyph in the comment field, I
don't have even an error, with :
exec($cmd, $Infos, $ExitStatus);

$Infos and $ExitStatus are empty...

In fact, in the meantime, I've found another solution, for the time
being : don't read comment field.

then my $cmd has to be completed :
$options = '-s -c \"%.8f\" ' . $data['short_options'];
$cmd = "$EXIFTOOL $options" . $data['PATH'];

with :

$EXIFTOOL = "/usr/local/bin/exiftool";

and "$data['short_options']" build from :
$SHORT_INFOS = array();
$SHORT_INFOS['XMP'] = ['Lens'];
$SHORT_INFOS['EXIF'] = explode(' ', 'Make Model ExposureTime FNumber ISO
FlashMode FocalLength');

$data['short_options'] = getOptions($SHORT_INFOS);

function getOptions($tab) {
$out = ' ';
foreach ($tab as $key => $fields){
foreach($fields as $field) {
$out .= "-$key:$field ";
}
}
return $out;
}

[Une Bévue]

Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> Adobe is probably just using
> something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
> like Windows-1250 or Windows-1252.

I do agree with that, because when using exiftool by command line on
terminal I get a question mark in a square instead of ®.
Generally it is due to ISO-8859-1 coded character in US_ASCII / UTF-8.
By terminal (macOS Sierra) works well with UTF-8 even with 🍺...

[Une Bévue]

Le 14/12/2016 à 23:19, Eli the Bearded a écrit :

> Not-so-much faulty as software that doesn't understand character set
> encodings.

In fact, after reading the photo content it appears that the only wrong
"character" is Ⓡ (C2 AE in UTF-8) encoded in MacRoman as "A8" in this
file who's encoding is UTF-8.

No way to change that any :
-charset exif=MacRoman, doesn't work.

[R.Wieser]

Thomas,

> Utter nonsense.

Poppycock.

> Not displayed, but output.

Not output, just stored.

> And, if you cared to read, they are using the output of an external
program.

You say that is if its important. Which it isn't.

> And Santa Claus comes down the chimney.

Actually that sounds less dumb than you "you just match your local language
setting with whatever is used in the image" suggestion. Really doable when
those pictures could come from sources (people as well as devices) the OP
has absolutily no control over.

And there has even been talk that Santa can "fold" himself so he can even
pass thru the smallest of airducts, to visit the good kids in homes without
a fireplace. :-)

> I would have killfiled you for this if that were not done automatically
> already because of your anti-social address munging on top of your anti-
> social denying to post with your real name. FOAD.

Lol. You would just doing me a favour, as I can than just warn other
people without you posting another of your obnoxious "I'm the president of
the internet, heed my demands" posts. :-)

Besides, you're lying. You neither killfile, nor are doing it
automatically. How I know that ? Because we met before where you said
pretty-much the same and you *still* respond to my posts. :-)

> because of your anti-social address munging on top of your

> anti-social denying to post with your real name

Lol again. The hypocrite demanding something he refuses to give himself,
and just plain stupid enough to not being able to understand, in this
time-and-age of internet spam, why email adresses are being kept private.

Regards,
Rudy Wieser


-- Origional message:
Thomas 'PointedEars' Lahn <Point...@web.de> schreef in berichtnieuws

2144039.j...@PointedEars.de...

[R.Wieser]

Une,

I don't think its unsolvable, but maybe it takes a bit more work.

Going back to your first post:

$EXIFTOOL = '/usr/local/bin/exiftool';
$cmd = "$EXIFTOOL " . $data['PATH'];
exec($cmd, $Infos, $ExitStatus);
foreach($Infos as $line) {
$fields = explode(' : ', $line, 2 );
if(count($fields) == 2) {
$data[rtrim($fields[0])] = $fields[1];
}
}
$data['ExitStatus'] = $ExitStatus;

Have you ever display the contents of the $Infos array (print_r) ? Did it
contain anything ? If it does, have you displayed the contents of each
$line ?

If $Infos doesn't contain anything you might do a google for information
about that "exec" command in combination with character encodings.

But if you just want the data you could try to output the exif data into a
file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
contains the data. If it does you could see what happens when you try to
parse that file (even if it does not work you're likely to get a usable
error).

Regards,
Rudy Wieser


-- Origional message:

Une Bévue <unbe...@fai.invalid> schreef in berichtnieuws
o32o8o$ec2$1...@shakotay.alphanet.ch...

> Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> > Not-so-much faulty as software that doesn't understand character set
> > encodings.
>
> In fact, after reading the photo content it appears that the only wrong

> "character" is ? (C2 AE in UTF-8) encoded in MacRoman as "A8" in this

[Une Bévue]

Le 17/12/2016 à 09:26, R.Wieser a écrit :
> Have you ever display the contents of the $Infos array (print_r) ? Did it
> contain anything ? If it does, have you displayed the contents of each
> $line ?

As I said : no output at all !

> If $Infos doesn't contain anything you might do a google for information
> about that "exec" command in combination with character encodings.

Yes, right, but, from carfull hex reding of the datascontained in this
photo, the encoding of the exif part (and like) is in UTF-8 only one
character is in MacRoman.

> But if you just want the data you could try to output the exif data into a
> file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
> contains the data. If it does you could see what happens when you try to
> parse that file (even if it does not work you're likely to get a usable
> error).

Obviously, this should work reading the "temp.dat" in byte mode (as of a
binary file) then, rewriting "A8" (ie. MacRoman) to "C2 AE" (UTF-8).

Rather heavy for one char isnt'it?

I'll try that this afternoon...

[R.Wieser]

Une,

> > Have you ever display the contents of the $Infos array (print_r) ?
> > Did it contain anything ? If it does, have you displayed the contents
> > of each $line ?
>
> As I said : no output at all !

Yeah, but as far as I can tell you have just been looking at the $data array
result, not at any of the intermediate variables. Correct me if I'm
wrong.

> Obviously, this should work reading the "temp.dat" in byte mode

You do not understand: If that file gets filled with data it stands to
reason that the $Infos variable also gets filled. If the file gets filled
but the variable not then there would be something rather odd on, possibly
with the "exec" command (on the other hand, that "exec" command may be
exactly doing what its told to do, and we simply are not aware of what it
has been told :-) ).

In other words: I'm not working towards a solution, I'm working towards
figuring out where the problem actually occurs, and what causes it. Which
those two in hand you're much more likely to find a/the solution.

Also, with that temp file you have a possibility to check what's *really*
been outputted. Maybe you'll even find that there is a ctrl-z in there
(EOF), causing the capturing of standard output (from the exiftool) to
terminate early. Who knows.

> Rather heavy for one char isnt'it?

If its really only for that one character, and you already have a method to
deal with it than I could agree with you. But as you have no idea what
actually causes the problem of the character resulting in an emptyresult you
might be bumping into other characters causing the same effect too. And
ofcourse, if we may take Murphy's Law as a guideline, at the most
in-opportune moment imaginable. :-)

Regards,
Rudy Wieser


-- Origional message:

Une Bévue <unbewus...@fai.invalid> schreef in berichtnieuws
o331fg$vqi$1...@shakotay.alphanet.ch...

[Jerry Stuckle]

That's Pointed Head for you, Rudy. He never has anything positive to
add to a conversation but demands everyone follow *his* rules. Its no
wonder he is known as a troll in so many newsgroups.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Une Bévue]

Le 17/12/2016 à 11:41, R.Wieser a écrit :
> Une,
>
>>> Have you ever display the contents of the $Infos array (print_r) ?
>>> Did it contain anything ? If it does, have you displayed the contents
>>> of each $line ?
>> As I said : no output at all !
> Yeah, but as far as I can tell you have just been looking at the $data array
> result, not at any of the intermediate variables. Correct me if I'm
> wrong.

No no, because $Infos is supposed to be an array, I've put in data output :

$data['count_infos'] = count($Infos);

giving 0

also I've tried :

shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);

no "/path/to/some.file" created.

another way, with system :

$result = system($cmd, $ExitStatus);

and with intermediate file :

$result = system("$cmd > /path/to/some.file", $ExitStatus);

again no "/path/to/some.file" created.

in both cases $result = ''
and $ExitStatus = 1

doing the same on terminal using :
$ exiftool 20161202_085945.jpg > 20161202_085945.txt
$ cat 20161202_085945.txt
ExifTool Version Number : 10.20
File Name : 20161202_085945.jpg
Directory : .

[...]

Comment : File written by Adobe Photoshop� 5.0

[...]

Circle Of Confusion : 0.004 mm
Field Of View : 60.3 deg
Focal Length : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance : 1.47 m

>> Obviously, this should work reading the "temp.dat" in byte mode
> You do not understand: If that file gets filled with data it stands to
> reason that the $Infos variable also gets filled.

right, however, see above...

> If the file gets filled
> but the variable not then there would be something rather odd on, possibly
> with the "exec" command (on the other hand, that "exec" command may be
> exactly doing what its told to do, and we simply are not aware of what it
> has been told :-) ).
>
> In other words: I'm not working towards a solution, I'm working towards
> figuring out where the problem actually occurs, and what causes it. Which
> those two in hand you're much more likely to find a/the solution.

right

> Also, with that temp file you have a possibility to check what's *really*
> been outputted. Maybe you'll even find that there is a ctrl-z in there
> (EOF), causing the capturing of standard output (from the exiftool) to
> terminate early. Who knows.

here I don't understand really your speaking because, i did this
experiment using command line on Terminal where I see � instead of ®.
even I examined the photo file itself using on hex Editor (reading the
file as a binary one and listing all the bytes in hex format).

>> Rather heavy for one char isnt'it?
> If its really only for that one character, and you already have a method to
> deal with it than I could agree with you. But as you have no idea what
> actually causes the problem of the character resulting in an emptyresult you
> might be bumping into other characters causing the same effect too. And
> ofcourse, if we may take Murphy's Law as a guideline, at the most
> in-opportune moment imaginable. :-)

you're right again, Murphy's Law must be my guideline here.

> Regards,
> Rudy Wieser

[R.Wieser]

Une,

> No no, because $Infos is supposed to be an array,

I know. Thats why I suggested that "print_p" command. It can display the
contents of an array. Like so: "print_p($Infos)".

... though I just noticed that I'm using "print_r" myself instead ....

> $data['count_infos'] = count($Infos);
>
> giving 0

Well, you're right in that that is a good indication nothing is in there.

> also I've tried :
>
> shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);
>
> no "/path/to/some.file" created.

Have you tried that with any of the images which normally do give usefull
output ? They certainly should give some output. If they also don't than
maybe the method we're trying to use is incorrect.

... I've just tested what would happen when I would use that command myself
(using a ZWAMP installation, PHP 5.3.3), and have no problems with either
capturing a programs output, or redirecting it to a file.

I also made the program output all characters from 0x01 thru 0xFF, and had
no problem with capturing that output either.

So, I can't recreate your problem and I'm also outof ideas to try. Sorry.

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewus...@fai.invalid> schreef in berichtnieuws

o33pop$ccm$1...@shakotay.alphanet.ch...

> Comment : File written by Adobe Photoshop? 5.0

> experiment using command line on Terminal where I see ? instead of ®.

[Une Bévue]

Le 18/12/2016 à 10:27, R.Wieser a écrit :
> Have you tried that with any of the images which normally do give usefull
> output ?

Obviously, yes, that gaves me the correct number of lines.

[R.Wieser]

Une,

> Obviously,

:-) For you that might be. For large swats of people its not. And even
for the smarter 'uns it simply might have simply slipped their mind.

> yes, that gaves me the correct number of lines.

Good. I asked to make sure that the problem was indeed only present with
that one image. You might be amazed how many people forget that kind of
stuff, and only after days of effort suddenly find the problem is not at all
unique to to what they thought it was.

But as I already said, I'm out of ideas.

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewus...@fai.invalid> schreef in berichtnieuws

o3dlum$uro$1...@shakotay.alphanet.ch...

[Une Bévue]

Le 21/12/2016 à 16:58, R.Wieser a écrit :
> But as I already said, I'm out of ideas.

me 2

best,

Yvon