On Tue, Jan 13, 2015 at 7:08 PM, Fernando de Oliveira <[email protected]>
wrote:

> On 13-01-2015 18:30, alex lupu wrote:
> > BLFS Book version 2015-01-12,  PHP-5.6.4
> >
> > 1.  I do not understand this move:
> >
> > mv -v /etc/php-fpm.conf{.default,}
>
> It is using brace expansion. It is an excellent form to decrease the
> size of commands, by writing only once the common part.
>
> Try:
>
> $ echo /etc/php-fpm.conf{.default,}
> /etc/php-fpm.conf.default /etc/php-fpm.conf
>
> This means that
>
> mv -v /etc/php-fpm.conf{.default,}
>
> is equivalent to
>
> mv -v /etc/php-fpm.conf.default /etc/php-fpm.conf
>
> See, e.g. "Bash Brace Expansion Tutorial: 6 Examples of Expanding
> Expressions within Braces":
>
> http://www.thegeekstuff.com/2010/06/bash-shell-brace-expansion/

​
Hi Fernando,​

​My problem was I never found a file 'php-fpm.conf.default' in '/etc' or
anywhere else, so the mv command would _fail_, from my standpoint {whether
I had any idea about those braces or not :}.

The mystery (i.e., the apparent _missing_ 'php-fpm.conf.default' file - to
be later renamed to 'php-fpm.conf' by the mv command) is two-fold:

1.  In the source/working directory "php-5.6.4" there is a file named
./sapi/fpm/php-fpm.conf
_identical_ (content, time-stamp) with the one in '/etc', which leads me to
believe that it (./sapi/fpm/php-fpm.conf) was the one copied to '/etc'
during 'make install'.

I'm skeptical it was copied as '/etc/php-fpm.conf.default' (thus the need
for the mv command to rename it back - which failed, as I said).
I have no 100% proof one way or the other because

2.  The log of the 'make install' command is very cryptic in this respect.
It does have a "suspicious" line:

"Installing PHP FPM config:        /etc/"

which _may_ refer to this copy (I can drill down into this "Installing ..."
business
to see exactly what it does behind the scenes but life is too short and the
subject is really unimportant, even in the smaller scheme of things).

As an aside, the other two, 'pear.conf' and 'php.ini' end up in '/etc' with
their names intact, at the very same time as the 'php-fpm.conf' file.

Be that as it may, if anybody who might happen to install php-5.6.4
sometime in the future would be willing to look into what really happens to
'php-fpm.conf' on 'make install', that will definitely advance the outer
edges of science.

Anyway, many thanks for you interest and help.
​

> > 2.  Under
> >  For the "Single HTML" file:
> >
> > I downloaded 'php_manual_en.html.gz' (using wget, FWIW)
> >
> > and later, at
> >
> > gunzip -v /usr/share/doc/php-5.6.4/php_manual_en.html.gz
> >
> > 'gunzip' complained that the file was "not in gzip format"
> >
> > I tend to agree with gunzip:
> >
> > If I changed the name to just "php_manual_en.html" (for cleanliness),
> > 'lynx' (as a quick choice) could read it directly (and 'less' also liked
> > it).
>
> This does not happen to me:
> $ wget -c http://br1.php.net/get/php_manual_en.html.gz/from/this/mirror
> -O php_manual_en.html.gz
>
> (Without the -O ..., it downloads the same file, but with the name
> "mirror".
>
> $ file php_manual_en.html.gz
> php_manual_en.html.gz: gzip compressed data, was "php-bigxhtml.html",
> from Unix, last modified: Fri Jan  9 08:14:43 2015, max compression
>
​
My command has been
% wget http://www.php.net/php_manual_en.html.gz

I tried it again and got the same crazy result:

% file php_manual_en.html.gz
php_manual_en.html.gz: HTML document, ASCII text

% ls -og php_manual_en.html.gz
-rw-r--r-- 1 13696 2015-01-13 21:39 php_manual_en.html.gz

Best wishes,
-- Alex​
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to