Groups > comp.lang.php > #16110 > unrolled thread

parsing print_r() output with preg_match_all()

Started by	"R.Wieser" <address@not.available>
First post	2016-01-06 17:18 +0100
Last post	2016-01-12 16:11 +0100
Articles	20 on this page of 114 — 10 participants

Back to article view | Back to comp.lang.php

  parsing print_r() output with preg_match_all()  "R.Wieser" <address@not.available> - 2016-01-06 17:18 +0100
    Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-06 19:28 +0000
      Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-06 20:50 +0100
        Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-06 21:12 +0000
          Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 16:20 -0500
            Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 02:23 +0000
              Re: parsing print_r() output with preg_match_all() Matthew Carter <m@ahungry.com> - 2016-01-06 21:48 -0500
                Re: parsing print_r() output with preg_match_all() Matthew Carter <m@ahungry.com> - 2016-01-06 21:52 -0500
                  Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:20 +0100
                  Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 10:56 +0000
                    Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 12:55 +0100
                      Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 08:36 -0500
                      Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 13:58 +0000
                        Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 15:33 +0100
                          Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 15:31 +0000
                          Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 18:23 +0100
              Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 22:50 -0500
              Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:10 +0100
            Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 10:03 +0100
              Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 08:38 -0500
                Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 14:05 +0000
                  Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 13:42 -0500
                    Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 20:24 +0000
                      Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 15:27 -0500
          Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 09:51 +0100
            Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 11:18 +0000
              Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 14:00 +0100
                Re: parsing print_r() output with preg_match_all() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 14:00 +0000
                Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 16:19 +0100
        Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:11 +0100
          Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:04 -0500
            Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:48 +0100
              Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:41 +0100
                Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:53 -0500
                  Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:40 +0100
                    Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:12 -0500
                      Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 21:43 +0100
                        Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:12 -0500
                          Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 22:28 +0100
                            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:35 -0500
                              Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 06:39 +0100
                                Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-13 08:26 +0100
                                Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 08:10 -0500
                                  Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 14:49 +0100
                                    Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 10:08 -0500
                                      Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 18:50 +0100
                                        Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 15:06 -0500
                                          Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 23:11 +0100
                                            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 17:18 -0500
                                              Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-13 23:27 +0100
                                                Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 19:17 -0500
                                                  Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 01:30 +0100
                                                    Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 20:52 -0500
                                                      Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 08:13 +0100
                                                        Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 09:18 -0500
                                                          Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 20:07 +0100
                                                            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:06 -0500
                                                              Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 22:41 +0100
                                                    Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-14 22:35 +0100
                                  Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 10:24 +1300
                                    Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 17:20 -0500
                                      Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 12:14 +1300
                                        Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-13 19:18 -0500
                                          Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 08:34 +0100
                                            Re: parsing print_r() output with preg_match_all() Anders Wegge Keller <wegge@geostat.dk> - 2016-01-14 09:20 +0100
                                              Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-14 21:56 +1300
                                            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:08 -0500
                                              Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 22:55 +0100
                                                Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 16:59 -0500
                                                  Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-14 23:09 +0100
                                                    Re: parsing print_r() output with preg_match_all() Ian Collins <ian-news@hotmail.com> - 2016-01-15 11:17 +1300
                                                      Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 19:15 -0500
                                                    Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-14 19:14 -0500
              Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:50 -0500
                Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:42 +0100
                  Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 08:41 +0100
                  Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:13 -0500
                    Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 21:44 +0100
                      Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:13 -0500
                        Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 22:29 +0100
                          Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 16:33 -0500
          Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:49 +0100
            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:54 -0500
    Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 11:17 +0100
      Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 13:49 +0100
        Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 14:20 +0100
          Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 15:31 +0100
            Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 16:00 +0100
            Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 13:45 -0500
              Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-07 20:18 +0100
                Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-07 20:52 +0100
                  Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-07 15:29 -0500
              Re: parsing print_r() output with preg_match_all() Tim Streater <timstreater@greenbee.net> - 2016-01-07 22:42 +0000
                Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-08 10:43 +0100
    Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:07 +0100
      Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:05 -0500
        Re: parsing print_r() output with preg_match_all() Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:51 +0100
          Re: parsing print_r() output with preg_match_all() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-12 00:31 +0100
          Re: parsing print_r() output with preg_match_all() Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:55 -0500
          Re: parsing print_r() output with preg_match_all() "R.Wieser" <address@not.available> - 2016-01-12 11:11 +0100
            Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "R.Wieser" <address@not.available> - 2016-01-12 11:54 +0100
              Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-12 11:25 +0000
                Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "R.Wieser" <address@not.available> - 2016-01-12 13:41 +0100
                  Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 14:11 +0100
                    Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 14:34 +0100
                      Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 15:03 +0100
                        Re: parsing print_r() output with preg_match_all() - questionremainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 15:50 +0100
                          Re: parsing print_r() output with preg_match_all() - questionremainsunanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 16:36 +0100
                            Re: parsing print_r() output with preg_match_all() - Solved. "R.Wieser" <address@not.available> - 2016-01-12 21:28 +0100
                  Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-12 14:02 +0000
              Re: parsing print_r() output with preg_match_all() - question remains unanswered ... "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-01-12 12:42 +0100
                Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 14:20 +0100
              Re: parsing print_r() output with preg_match_all() - question remains unanswered ... Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-12 09:43 -0500
                Re: parsing print_r() output with preg_match_all() - question remainsunanswered ... "R.Wieser" <address@not.available> - 2016-01-12 16:11 +0100

Page 1 of 6 [1] 2 3 4 5 6 Next page →

#16110 — parsing print_r() output with preg_match_all()

From	"R.Wieser" <address@not.available>
Date	2016-01-06 17:18 +0100
Subject	parsing print_r() output with preg_match_all()
Message-ID	<568d3dcf$0$23748$e4fe514c@news.xs4all.nl>

Hello All,

I'm saving the contents of an array-of-arrays into a string with print_r().
Now I want to parse the contents of that string into an array-of-arrays
again.

I've found some code which is supposed to do that (at
http://nl3.php.net/print_r), but it seems to depend on TAB chars being
present in the output -- and those do not appear in mine.

So, I tried to alter the used regexp to the preg_match_all() function, which
is where all the fun started: I cannot seem to find a notation which will
just add the detection of a closing bracket (ending a sub-array).

Can anyone here lend me a hand ?

The offending line :

if (preg_match_all('/^\s+\[(\w+).*\] => (.*)\n/m', $printr, $match)) {

Example of the to-be-parsed array:

Array
(
    [item0] => Array
        (
            [0] => Array
                (
                    [key0_0_0] => Value_0_0_0
                    [key0_0_1] => Value_0_0_1
                )

            [1] => Array
                (
                    [key0_1_0] => Value_0_1_0
....
    [item1] => Array
        (
            [1] => Array
                (
                    [key1_1_0] => Value_1_1_0
....

Also, I do not have the slightest idea how the preg_match_all() function
determines which part of the parsed line is going in which column of the
resulting array. :-\

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#16113

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-06 19:28 +0000
Message-ID	<87r3huzevd.fsf@bsb.me.uk>
In reply to	#16110

"R.Wieser" <address@not.available> writes:

> I'm saving the contents of an array-of-arrays into a string with print_r().
> Now I want to parse the contents of that string into an array-of-arrays
> again.
>
> I've found some code which is supposed to do that (at
> http://nl3.php.net/print_r), but it seems to depend on TAB chars being
> present in the output -- and those do not appear in mine.
>
> So, I tried to alter the used regexp to the preg_match_all() function, which
> is where all the fun started: I cannot seem to find a notation which will
> just add the detection of a closing bracket (ending a sub-array).
>
> Can anyone here lend me a hand ?

It would be a lot simpler if you could switch to using serialize and
unserialize.  Do you need to use print_r for some other reason?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16114

From	"R.Wieser" <address@not.available>
Date	2016-01-06 20:50 +0100
Message-ID	<568d6f9c$0$23759$e4fe514c@news.xs4all.nl>
In reply to	#16113

Ben,

> It would be a lot simpler if you could switch to using
> serialize and unserialize.  Do you need to use print_r
> for some other reason?

I'm using it to store the array-of-arrays into a file in human-readable
format.  I intend to parse this file using another program, posibly alter
some info and write it back.

And thats the point where I wanted to use that regex to read the structure
back in.

Now you mention it, I've heard from serializing and unserializing, but
was/am assuming that its not really ment to be read/understood by humans.

But what's the problem with using that preg_match_all() ?

Regards,
Rudy Wieser

P.s.
I did find another problem: while experimenting with the filer and looking
at the $match variable with var_dump() I noticed that not all columns had
the same length.  Which explains why my debugging output of a row of array
elements seemed to be wonkey. :-\

-- Origional message:
Ben Bacarisse <ben.usenet@bsb.me.uk> schreef in berichtnieuws
87r3huzevd.fsf@bsb.me.uk...
> "R.Wieser" <address@not.available> writes:
>
> > I'm saving the contents of an array-of-arrays into a string with
print_r().
> > Now I want to parse the contents of that string into an array-of-arrays
> > again.
> >
> > I've found some code which is supposed to do that (at
> > http://nl3.php.net/print_r), but it seems to depend on TAB chars being
> > present in the output -- and those do not appear in mine.
> >
> > So, I tried to alter the used regexp to the preg_match_all() function,
which
> > is where all the fun started: I cannot seem to find a notation which
will
> > just add the detection of a closing bracket (ending a sub-array).
> >
> > Can anyone here lend me a hand ?
>
> It would be a lot simpler if you could switch to using serialize and
> unserialize.  Do you need to use print_r for some other reason?
>
> <snip>
> --
> Ben.

[toc] | [prev] | [next] | [standalone]

#16118

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-06 21:12 +0000
Message-ID	<87fuyaza37.fsf@bsb.me.uk>
In reply to	#16114

"R.Wieser" <address@not.available> writes:

>> It would be a lot simpler if you could switch to using
>> serialize and unserialize.  Do you need to use print_r
>> for some other reason?
>
> I'm using it to store the array-of-arrays into a file in human-readable
> format.  I intend to parse this file using another program, posibly alter
> some info and write it back.

Well the output of serialise is human-readable (just about).  It's not
ideal, but then parsing print_r output is not ideal either.  In fact,
it's not even possible in all cases though you may be able to make
enough assumptions about what's in the strings to get away with it.

But I would seriously consider some other plan.  If it's always going to
be just an array of arrays of strings, you could design your own
human-readable format whilst making it (much) easier to read back.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16119

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2016-01-06 16:20 -0500
Message-ID	<n6k0a5$od7$1@jstuckle.eternal-september.org>
In reply to	#16118

On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
> "R.Wieser" <address@not.available> writes:
> 
>>> It would be a lot simpler if you could switch to using
>>> serialize and unserialize.  Do you need to use print_r
>>> for some other reason?
>>
>> I'm using it to store the array-of-arrays into a file in human-readable
>> format.  I intend to parse this file using another program, posibly alter
>> some info and write it back.
> 
> Well the output of serialise is human-readable (just about).  It's not
> ideal, but then parsing print_r output is not ideal either.  In fact,
> it's not even possible in all cases though you may be able to make
> enough assumptions about what's in the strings to get away with it.
> 
> But I would seriously consider some other plan.  If it's always going to
> be just an array of arrays of strings, you could design your own
> human-readable format whilst making it (much) easier to read back.
> 
> <snip>
> 

I agree - I wouldn't try to parse the output of print_r().  It's not
made to be parsed, and there is no documentation on the output, AFAICR,
which means the format could change with a different release of PHP.

XML comes to mind. Human readable and made to be easily parsed.

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

[toc] | [prev] | [next] | [standalone]

#16122

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-07 02:23 +0000
Message-ID	<874meqyvo5.fsf@bsb.me.uk>
In reply to	#16119

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
>> "R.Wieser" <address@not.available> writes:
>> 
>>>> It would be a lot simpler if you could switch to using
>>>> serialize and unserialize.  Do you need to use print_r
>>>> for some other reason?
>>>
>>> I'm using it to store the array-of-arrays into a file in human-readable
>>> format.  I intend to parse this file using another program, posibly alter
>>> some info and write it back.
>> 
>> Well the output of serialise is human-readable (just about).  It's not
>> ideal, but then parsing print_r output is not ideal either.  In fact,
>> it's not even possible in all cases though you may be able to make
>> enough assumptions about what's in the strings to get away with it.
>> 
>> But I would seriously consider some other plan.  If it's always going to
>> be just an array of arrays of strings, you could design your own
>> human-readable format whilst making it (much) easier to read back.
>> 
>> <snip>
>> 
>
> I agree - I wouldn't try to parse the output of print_r().  It's not
> made to be parsed, and there is no documentation on the output, AFAICR,
> which means the format could change with a different release of PHP.
>
> XML comes to mind. Human readable and made to be easily parsed.

Feels like overkill to me but it's hard to know what's really going on
here.  There are much simpler formats for representing an array of
arrays of strings which might pay off in this simple case.

The OP might also look into JSON and var_export+eval (the latter needing
care unless the file has the same status as code) but these are all
rather "noisy", like XML.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16123

From	Matthew Carter <m@ahungry.com>
Date	2016-01-06 21:48 -0500
Message-ID	<87y4c2umsm.fsf@ahungry.com>
In reply to	#16122

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
>>> "R.Wieser" <address@not.available> writes:
>>> 
>>>>> It would be a lot simpler if you could switch to using
>>>>> serialize and unserialize.  Do you need to use print_r
>>>>> for some other reason?
>>>>
>>>> I'm using it to store the array-of-arrays into a file in human-readable
>>>> format.  I intend to parse this file using another program, posibly alter
>>>> some info and write it back.
>>> 
>>> Well the output of serialise is human-readable (just about).  It's not
>>> ideal, but then parsing print_r output is not ideal either.  In fact,
>>> it's not even possible in all cases though you may be able to make
>>> enough assumptions about what's in the strings to get away with it.
>>> 
>>> But I would seriously consider some other plan.  If it's always going to
>>> be just an array of arrays of strings, you could design your own
>>> human-readable format whilst making it (much) easier to read back.
>>> 
>>> <snip>
>>> 
>>
>> I agree - I wouldn't try to parse the output of print_r().  It's not
>> made to be parsed, and there is no documentation on the output, AFAICR,
>> which means the format could change with a different release of PHP.
>>
>> XML comes to mind. Human readable and made to be easily parsed.
>
> Feels like overkill to me but it's hard to know what's really going on
> here.  There are much simpler formats for representing an array of
> arrays of strings which might pay off in this simple case.
>
> The OP might also look into JSON and var_export+eval (the latter needing
> care unless the file has the same status as code) but these are all
> rather "noisy", like XML.

JSON is pretty reasonable to read if line breaks/indentation is added
(it has the benefit of easily being encoded/decoded as well, even if
line breaks are present).

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#16124

From	Matthew Carter <m@ahungry.com>
Date	2016-01-06 21:52 -0500
Message-ID	<87twmqumn9.fsf@ahungry.com>
In reply to	#16123

Matthew Carter <m@ahungry.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
>>>> "R.Wieser" <address@not.available> writes:
>>>> 
>>>>>> It would be a lot simpler if you could switch to using
>>>>>> serialize and unserialize.  Do you need to use print_r
>>>>>> for some other reason?
>>>>>
>>>>> I'm using it to store the array-of-arrays into a file in human-readable
>>>>> format.  I intend to parse this file using another program, posibly alter
>>>>> some info and write it back.
>>>> 
>>>> Well the output of serialise is human-readable (just about).  It's not
>>>> ideal, but then parsing print_r output is not ideal either.  In fact,
>>>> it's not even possible in all cases though you may be able to make
>>>> enough assumptions about what's in the strings to get away with it.
>>>> 
>>>> But I would seriously consider some other plan.  If it's always going to
>>>> be just an array of arrays of strings, you could design your own
>>>> human-readable format whilst making it (much) easier to read back.
>>>> 
>>>> <snip>
>>>> 
>>>
>>> I agree - I wouldn't try to parse the output of print_r().  It's not
>>> made to be parsed, and there is no documentation on the output, AFAICR,
>>> which means the format could change with a different release of PHP.
>>>
>>> XML comes to mind. Human readable and made to be easily parsed.
>>
>> Feels like overkill to me but it's hard to know what's really going on
>> here.  There are much simpler formats for representing an array of
>> arrays of strings which might pay off in this simple case.
>>
>> The OP might also look into JSON and var_export+eval (the latter needing
>> care unless the file has the same status as code) but these are all
>> rather "noisy", like XML.
>
> JSON is pretty reasonable to read if line breaks/indentation is added
> (it has the benefit of easily being encoded/decoded as well, even if
> line breaks are present).

Oh, and that can be done with builtins:

<?php

$array = [
  'Hello' => [
    'World' => true,
    'Goodbye' => true,
  ],
];

echo json_encode($array, JSON_PRETTY_PRINT);

Gives nice output like:

{
    "Hello": {
        "World": true,
        "Goodbye": true
    }
}

You also get the bonus effect of having your output ready made parseable
by every language/utility under the sun.


-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#16130

From	"R.Wieser" <address@not.available>
Date	2016-01-07 10:20 +0100
Message-ID	<568e2d5f$0$23811$e4fe514c@news.xs4all.nl>
In reply to	#16124

Matthew,

> Gives nice output like:
[snip]
> You also get the bonus effect of having your output ready
> made parseable by every language/utility under the sun.

I'm sorry, but I do not see much, if any difference between those two
structures.  They look to be equal in regard to parseability to me ...

... and neither look like the example I included in my initial message ...

Regards,
Rudy Wieser


-- Origional message:
Matthew Carter <m@ahungry.com> schreef in berichtnieuws
87twmqumn9.fsf@ahungry.com...
> Matthew Carter <m@ahungry.com> writes:
>
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >
> >> Jerry Stuckle <jstucklex@attglobal.net> writes:
> >>
> >>> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
> >>>> "R.Wieser" <address@not.available> writes:
> >>>>
> >>>>>> It would be a lot simpler if you could switch to using
> >>>>>> serialize and unserialize.  Do you need to use print_r
> >>>>>> for some other reason?
> >>>>>
> >>>>> I'm using it to store the array-of-arrays into a file in
human-readable
> >>>>> format.  I intend to parse this file using another program, posibly
alter
> >>>>> some info and write it back.
> >>>>
> >>>> Well the output of serialise is human-readable (just about).  It's
not
> >>>> ideal, but then parsing print_r output is not ideal either.  In fact,
> >>>> it's not even possible in all cases though you may be able to make
> >>>> enough assumptions about what's in the strings to get away with it.
> >>>>
> >>>> But I would seriously consider some other plan.  If it's always going
to
> >>>> be just an array of arrays of strings, you could design your own
> >>>> human-readable format whilst making it (much) easier to read back.
> >>>>
> >>>> <snip>
> >>>>
> >>>
> >>> I agree - I wouldn't try to parse the output of print_r().  It's not
> >>> made to be parsed, and there is no documentation on the output,
AFAICR,
> >>> which means the format could change with a different release of PHP.
> >>>
> >>> XML comes to mind. Human readable and made to be easily parsed.
> >>
> >> Feels like overkill to me but it's hard to know what's really going on
> >> here.  There are much simpler formats for representing an array of
> >> arrays of strings which might pay off in this simple case.
> >>
> >> The OP might also look into JSON and var_export+eval (the latter
needing
> >> care unless the file has the same status as code) but these are all
> >> rather "noisy", like XML.
> >
> > JSON is pretty reasonable to read if line breaks/indentation is added
> > (it has the benefit of easily being encoded/decoded as well, even if
> > line breaks are present).
>
> Oh, and that can be done with builtins:
>
> <?php
>
> $array = [
>   'Hello' => [
>     'World' => true,
>     'Goodbye' => true,
>   ],
> ];
>
> echo json_encode($array, JSON_PRETTY_PRINT);
>
> Gives nice output like:
>
> {
>     "Hello": {
>         "World": true,
>         "Goodbye": true
>     }
> }
>
> You also get the bonus effect of having your output ready made parseable
> by every language/utility under the sun.
>
> --
> Matthew Carter (m@ahungry.com)
> http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#16132

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-07 10:56 +0000
Message-ID	<87k2nly7x3.fsf@bsb.me.uk>
In reply to	#16124

Matthew Carter <m@ahungry.com> writes:

> Matthew Carter <m@ahungry.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
<snip>
>>>>> "R.Wieser" <address@not.available> writes:
<snip>
>>>>>> I'm using it to store the array-of-arrays into a file in human-readable
>>>>>> format.  I intend to parse this file using another program, posibly alter
>>>>>> some info and write it back.
<snip>
>>> The OP might also look into JSON and var_export+eval (the latter needing
>>> care unless the file has the same status as code) but these are all
>>> rather "noisy", like XML.
>>
>> JSON is pretty reasonable to read if line breaks/indentation is added
>> (it has the benefit of easily being encoded/decoded as well, even if
>> line breaks are present).
>
> Oh, and that can be done with builtins:
>
> <?php
>
> $array = [
>   'Hello' => [
>     'World' => true,
>     'Goodbye' => true,
>   ],
> ];
>
> echo json_encode($array, JSON_PRETTY_PRINT);
>
> Gives nice output like:
>
> {
>     "Hello": {
>         "World": true,
>         "Goodbye": true
>     }
> }

The trouble is going the other way.  I could not find a way to get
json_decode to give you the original array back -- by default you get an
object.  There's mention of JSON_OBJECT_AS_ARRAY in the user comments
but I can't find the definitive documentation about this (and it's not
defined by my current version of PHP).

This is why I just said "look into JSON" rather than "I'd use JSON".

> You also get the bonus effect of having your output ready made parseable
> by every language/utility under the sun.

Yes, if the array/object issue can be fixed or if it does not matter to
the OP, JSON is the front runner.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16134

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2016-01-07 12:55 +0100
Message-ID	<8027862.ZV2veRrZ9M@PointedEars.de>
In reply to	#16132

Ben Bacarisse wrote:

> Matthew Carter <m@ahungry.com> writes:
>> $array = [
>>   'Hello' => [
>>     'World' => true,
>>     'Goodbye' => true,
>>   ],
>> ];
>>
>> echo json_encode($array, JSON_PRETTY_PRINT);
>>
>> Gives nice output like:
>>
>> {
>>     "Hello": {
>>         "World": true,
>>         "Goodbye": true
>>     }
>> }
> 
> The trouble is going the other way.  I could not find a way to get
> json_decode to give you the original array back -- by default you get an
> object.  There's mention of JSON_OBJECT_AS_ARRAY in the user comments
> but I can't find the definitive documentation about this (and it's not
> defined by my current version of PHP).

You cannot get the original array back, but you can easily get an equivalent 
associative array back instead of an object:

---------------------------------------------------------------------------
$ php -r 'var_dump(json_decode("{\"Hello\": {\"World\": true, \"Goodbye\": 
true}}", true));'
array(1) {
  'Hello' =>
  array(2) {
    'World' =>
    bool(true)
    'Goodbye' =>
    bool(true)
  }
}
---------------------------------------------------------------------------

Presumably, support for JSON_OBJECT_AS_ARRAY === 1, which is still defined, 
was removed because of that:

---------------------------------------------------------------------------
$ php -r 'var_dump(JSON_OBJECT_AS_ARRAY);'
int(1)

$ php -v
PHP 5.6.14-0+deb8u1 (cli) (built: Oct  4 2015 16:13:10) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend 
Technologies
    with Xdebug v2.3.3, Copyright (c) 2002-2015, by Derick Rethans
---------------------------------------------------------------------------

<http://php.net/json_decode>

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16138

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2016-01-07 08:36 -0500
Message-ID	<n6lpfv$cj7$1@jstuckle.eternal-september.org>
In reply to	#16134

On 1/7/2016 6:55 AM, Thomas 'Pointed Head' Lahn wrote:
> Ben Bacarisse wrote:
> 
>> Matthew Carter <m@ahungry.com> writes:
>>> $array = [
>>>   'Hello' => [
>>>     'World' => true,
>>>     'Goodbye' => true,
>>>   ],
>>> ];
>>>
>>> echo json_encode($array, JSON_PRETTY_PRINT);
>>>
>>> Gives nice output like:
>>>
>>> {
>>>     "Hello": {
>>>         "World": true,
>>>         "Goodbye": true
>>>     }
>>> }
>>
>> The trouble is going the other way.  I could not find a way to get
>> json_decode to give you the original array back -- by default you get an
>> object.  There's mention of JSON_OBJECT_AS_ARRAY in the user comments
>> but I can't find the definitive documentation about this (and it's not
>> defined by my current version of PHP).
> 
> You cannot get the original array back, but you can easily get an equivalent 
> associative array back instead of an object:
> 
> ---------------------------------------------------------------------------
> $ php -r 'var_dump(json_decode("{\"Hello\": {\"World\": true, \"Goodbye\": 
> true}}", true));'
> array(1) {
>   'Hello' =>
>   array(2) {
>     'World' =>
>     bool(true)
>     'Goodbye' =>
>     bool(true)
>   }
> }
> ---------------------------------------------------------------------------
> 
> Presumably, support for JSON_OBJECT_AS_ARRAY === 1, which is still defined, 
> was removed because of that:
> 
> ---------------------------------------------------------------------------
> $ php -r 'var_dump(JSON_OBJECT_AS_ARRAY);'
> int(1)
> 
> $ php -v
> PHP 5.6.14-0+deb8u1 (cli) (built: Oct  4 2015 16:13:10) 
> Copyright (c) 1997-2015 The PHP Group
> Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
>     with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend 
> Technologies
>     with Xdebug v2.3.3, Copyright (c) 2002-2015, by Derick Rethans
> ---------------------------------------------------------------------------
> 
> <http://php.net/json_decode>
> 

From this page:

Currently only JSON_BIGINT_AS_STRING is supported

JSON_OBJECT_AS_ARRAY may still be defined, but it is not supported.

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

[toc] | [prev] | [next] | [standalone]

#16140

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-07 13:58 +0000
Message-ID	<871t9txzil.fsf@bsb.me.uk>
In reply to	#16134

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Matthew Carter <m@ahungry.com> writes:
>>> $array = [
>>>   'Hello' => [
>>>     'World' => true,
>>>     'Goodbye' => true,
>>>   ],
>>> ];
>>>
>>> echo json_encode($array, JSON_PRETTY_PRINT);
>>>
>>> Gives nice output like:
>>>
>>> {
>>>     "Hello": {
>>>         "World": true,
>>>         "Goodbye": true
>>>     }
>>> }
>> 
>> The trouble is going the other way.  I could not find a way to get
>> json_decode to give you the original array back -- by default you get an
>> object.

I should have said "when there are mixed numeric and string keys".

>> There's mention of JSON_OBJECT_AS_ARRAY in the user comments
>> but I can't find the definitive documentation about this (and it's not
>> defined by my current version of PHP).
>
> You cannot get the original array back, but you can easily get an equivalent 
> associative array back instead of an object:
>
> ---------------------------------------------------------------------------
> $ php -r 'var_dump(json_decode("{\"Hello\": {\"World\": true, \"Goodbye\": 
> true}}", true));'
> array(1) {
>   'Hello' =>
>   array(2) {
>     'World' =>
>     bool(true)
>     'Goodbye' =>
>     bool(true)
>   }
> }
> ---------------------------------------------------------------------------
>
> Presumably, support for JSON_OBJECT_AS_ARRAY === 1, which is still defined, 
> was removed because of that:
>
> ---------------------------------------------------------------------------
> $ php -r 'var_dump(JSON_OBJECT_AS_ARRAY);'
> int(1)

I must have been misspelling it because, yes, it is still defined in my
version.  Not sure what it was ever for because (as you say) the assoc
parameter does what's needed at least in this case.

To the OP: I'd say, now, that pretty-printed JSON is the front runner.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16145

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2016-01-07 15:33 +0100
Message-ID	<2593390.uV5jh8T4Yt@PointedEars.de>
In reply to	#16140

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Matthew Carter <m@ahungry.com> writes:
>>>> echo json_encode($array, JSON_PRETTY_PRINT);
>>>>
>>>> Gives nice output like:
>>>>
>>>> {
>>>>     "Hello": {
>>>>         "World": true,
>>>>         "Goodbye": true
>>>>     }
>>>> }
>>> 
>>> The trouble is going the other way.  I could not find a way to get
>>> json_decode to give you the original array back -- by default you get an
>>> object.
> 
> I should have said "when there are mixed numeric and string keys".

There are no numeric keys in proper JSON (as in ECMAScript, all keys are 
strings), and I do not see the problem:

$ php -r 'var_dump(json_decode(json_encode([1 => 42, "foo" => "bar"]), 
true));'
array(2) {
  [1] =>
  int(42)
  'foo' =>
  string(3) "bar"
}

$ php -r 'var_dump(array_keys(json_decode(json_encode([1 => 2, "foo" => 
"bar"]), true, 512, JSON_OBJECT_AS_ARRAY)));'
array(2) {
  [0] =>
  int(1)
  [1] =>
  string(3) "foo"
}
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16148

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-01-07 15:31 +0000
Message-ID	<87r3htv22i.fsf@bsb.me.uk>
In reply to	#16145

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> Matthew Carter <m@ahungry.com> writes:
>>>>> echo json_encode($array, JSON_PRETTY_PRINT);
>>>>>
>>>>> Gives nice output like:
>>>>>
>>>>> {
>>>>>     "Hello": {
>>>>>         "World": true,
>>>>>         "Goodbye": true
>>>>>     }
>>>>> }
>>>> 
>>>> The trouble is going the other way.  I could not find a way to get
>>>> json_decode to give you the original array back -- by default you get an
>>>> object.
>> 
>> I should have said "when there are mixed numeric and string keys".
>
> There are no numeric keys in proper JSON (as in ECMAScript, all keys are 
> strings), and I do not see the problem:

"by default" meant when you use the function's default behaviour:

  $ php -r 'var_dump(json_decode(json_encode([1 => 42, "foo" => "bar"])));'  
  object(stdClass)#1 (2) {
    ["1"]=>
    int(42)
    ["foo"]=>
    string(3) "bar"
  }

But, as you say, easily fixed -- a fix I missed:

> $ php -r 'var_dump(json_decode(json_encode([1 => 42, "foo" => "bar"]), 
> true));'
> array(2) {
>   [1] =>
>   int(42)
>   'foo' =>
>   string(3) "bar"
> }

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16150

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2016-01-07 18:23 +0100
Message-ID	<2284570.LMhpeJnbiT@PointedEars.de>
In reply to	#16145

Thomas 'PointedEars' Lahn wrote:

> $ php -r 'var_dump(json_decode(json_encode([1 => 42, "foo" => "bar"]),
> true));'
> array(2) {
>   [1] =>
>   int(42)
>   'foo' =>
>   string(3) "bar"
> }
> 
> $ php -r 'var_dump(array_keys(json_decode(json_encode([1 => 2, "foo" =>
> "bar"]), true, 512, JSON_OBJECT_AS_ARRAY)));'

JFTR: The 512 and JSON_OBJECT_AS_ARRAY arguments are from testing if 
JSON_OBJECT_AS_ARRAY makes a difference; they can be safely omitted.

> array(2) {
>   [0] =>
>   int(1)
>   [1] =>
>   string(3) "foo"
> }
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16126

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2016-01-06 22:50 -0500
Message-ID	<n6kn4k$19v$1@jstuckle.eternal-september.org>
In reply to	#16122

On 1/6/2016 9:23 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
>>> "R.Wieser" <address@not.available> writes:
>>>
>>>>> It would be a lot simpler if you could switch to using
>>>>> serialize and unserialize.  Do you need to use print_r
>>>>> for some other reason?
>>>>
>>>> I'm using it to store the array-of-arrays into a file in human-readable
>>>> format.  I intend to parse this file using another program, posibly alter
>>>> some info and write it back.
>>>
>>> Well the output of serialise is human-readable (just about).  It's not
>>> ideal, but then parsing print_r output is not ideal either.  In fact,
>>> it's not even possible in all cases though you may be able to make
>>> enough assumptions about what's in the strings to get away with it.
>>>
>>> But I would seriously consider some other plan.  If it's always going to
>>> be just an array of arrays of strings, you could design your own
>>> human-readable format whilst making it (much) easier to read back.
>>>
>>> <snip>
>>>
>>
>> I agree - I wouldn't try to parse the output of print_r().  It's not
>> made to be parsed, and there is no documentation on the output, AFAICR,
>> which means the format could change with a different release of PHP.
>>
>> XML comes to mind. Human readable and made to be easily parsed.
> 
> Feels like overkill to me but it's hard to know what's really going on
> here.  There are much simpler formats for representing an array of
> arrays of strings which might pay off in this simple case.
> 
> The OP might also look into JSON and var_export+eval (the latter needing
> care unless the file has the same status as code) but these are all
> rather "noisy", like XML.
> 

I thought about json, but don't know how "readable" he wants it.  It
could  be an excellent solution, though.

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

[toc] | [prev] | [next] | [standalone]

#16128

From	"R.Wieser" <address@not.available>
Date	2016-01-07 10:10 +0100
Message-ID	<568e2b23$2$23766$e4fe514c@news.xs4all.nl>
In reply to	#16122

Ben,

> The OP might also look into JSON and var_export+eval
> (the latter needing care unless the file has the same status
> as code)

No "eval" (or comparable) please.  It may have its place when used with
internally generated stuff, but not when loading resources: to easy to be
abused or simply cause havock.

Regards,
Rudy Wieser

-- Origional message:
Ben Bacarisse <ben.usenet@bsb.me.uk> schreef in berichtnieuws
874meqyvo5.fsf@bsb.me.uk...
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
> > On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
> >> "R.Wieser" <address@not.available> writes:
> >>
> >>>> It would be a lot simpler if you could switch to using
> >>>> serialize and unserialize.  Do you need to use print_r
> >>>> for some other reason?
> >>>
> >>> I'm using it to store the array-of-arrays into a file in
human-readable
> >>> format.  I intend to parse this file using another program, posibly
alter
> >>> some info and write it back.
> >>
> >> Well the output of serialise is human-readable (just about).  It's not
> >> ideal, but then parsing print_r output is not ideal either.  In fact,
> >> it's not even possible in all cases though you may be able to make
> >> enough assumptions about what's in the strings to get away with it.
> >>
> >> But I would seriously consider some other plan.  If it's always going
to
> >> be just an array of arrays of strings, you could design your own
> >> human-readable format whilst making it (much) easier to read back.
> >>
> >> <snip>
> >>
> >
> > I agree - I wouldn't try to parse the output of print_r().  It's not
> > made to be parsed, and there is no documentation on the output, AFAICR,
> > which means the format could change with a different release of PHP.
> >
> > XML comes to mind. Human readable and made to be easily parsed.
>
> Feels like overkill to me but it's hard to know what's really going on
> here.  There are much simpler formats for representing an array of
> arrays of strings which might pay off in this simple case.
>
> The OP might also look into JSON and var_export+eval (the latter needing
> care unless the file has the same status as code) but these are all
> rather "noisy", like XML.
>
> --
> Ben.

[toc] | [prev] | [next] | [standalone]

#16129

From	"R.Wieser" <address@not.available>
Date	2016-01-07 10:03 +0100
Message-ID	<568e2b23$1$23766$e4fe514c@news.xs4all.nl>
In reply to	#16119

Jerry,

> XML comes to mind. Human readable and made to
> be easily parsed.

Its also like shooting a cannon at a musquito. :-)

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
n6k0a5$od7$1@jstuckle.eternal-september.org...
> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
> > "R.Wieser" <address@not.available> writes:
> >
> >>> It would be a lot simpler if you could switch to using
> >>> serialize and unserialize.  Do you need to use print_r
> >>> for some other reason?
> >>
> >> I'm using it to store the array-of-arrays into a file in human-readable
> >> format.  I intend to parse this file using another program, posibly
alter
> >> some info and write it back.
> >
> > Well the output of serialise is human-readable (just about).  It's not
> > ideal, but then parsing print_r output is not ideal either.  In fact,
> > it's not even possible in all cases though you may be able to make
> > enough assumptions about what's in the strings to get away with it.
> >
> > But I would seriously consider some other plan.  If it's always going to
> > be just an array of arrays of strings, you could design your own
> > human-readable format whilst making it (much) easier to read back.
> >
> > <snip>
> >
>
> I agree - I wouldn't try to parse the output of print_r().  It's not
> made to be parsed, and there is no documentation on the output, AFAICR,
> which means the format could change with a different release of PHP.
>
> XML comes to mind. Human readable and made to be easily parsed.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#16139

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2016-01-07 08:38 -0500
Message-ID	<n6lpjn$cj7$2@jstuckle.eternal-september.org>
In reply to	#16129

On 1/7/2016 4:03 AM, R.Wieser wrote:
> Jerry,
> 
>> XML comes to mind. Human readable and made to
>> be easily parsed.
> 
> Its also like shooting a cannon at a musquito. :-)
> 
> Regards,
> Rudy Wieser
> 
>

Not really.  It's exactly the type of job XML was designed for.  And it
is easily created and read.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 6 [1] 2 3 4 5 6 Next page →

csiph-web

parsing print_r() output with preg_match_all()

Contents

#16110 — parsing print_r() output with preg_match_all()

#16113

#16114

#16118

#16119

#16122

#16123

#16124

#16130

#16132

#16134

#16138

#16140

#16145

#16148

#16150

#16126

#16128

#16129

#16139