On Wed, Nov 19, 2014 at 11:12:43AM -0500, random...@fastmail.us wrote:
On Wed, Nov 19, 2014, at 09:55, Dimitris Papastamos wrote:
Regarding your question on cp -f then the answer is not quite.
cp -f will try to unlink the destination if it fails to open it for
whatever
reason.
And
On Thu, Nov 20, 2014, at 14:40, Markus Wichmann wrote:
Not always. One thing that reliably gets on people's nerves here is
shared libraries. And those aren't protected with that ETXTBSY thing.
The reason is that the MAP_DENYWRITE flag became the irrecoverable
source of a DoS attack and had
On Tue, Nov 18, 2014 at 03:49:36PM -0500, Wolfgang Corcoran-Mathe wrote:
Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:
Well, install doesn't do any magic.
There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
Quoth Dimitris Papastamos on Wed, Nov 19 2014 14:55 +:
On Tue, Nov 18, 2014 at 03:49:36PM -0500, Wolfgang Corcoran-Mathe wrote:
Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:
Well, install doesn't do any magic.
There is this.[1] But if the issue is unlinking a running target,
(a) how often
On Wed, Nov 19, 2014 at 10:22:19AM -0500, Wolfgang Corcoran-Mathe wrote:
Quoth Dimitris Papastamos on Wed, Nov 19 2014 14:55 +:
On Tue, Nov 18, 2014 at 03:49:36PM -0500, Wolfgang Corcoran-Mathe wrote:
Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:
Well, install doesn't do any magic.
There
On 18 November 2014 19:25, Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the install target of Makefile)?
To me the answer is rather obvious.
On Wed, Nov 19, 2014 at 4:41 PM, Anselm R Garbe garb...@gmail.com wrote:
On 18 November 2014 19:25, Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in
On Wed, Nov 19, 2014, at 09:55, Dimitris Papastamos wrote:
Regarding your question on cp -f then the answer is not quite.
cp -f will try to unlink the destination if it fails to open it for
whatever
reason.
And if the target is running and writing to a running binary is a
problem, opening
On 18 November 2014 19:25, Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the install target of Makefile)?
To me the answer is rather obvious.
Thats why gnu autoconf ships install-sh script ;) as a fallback when install is
not found
On 19 Nov 2014, at 20:36, k...@shike2.com wrote:
On 18 November 2014 19:25, Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are
On Wed, Nov 19, 2014 at 04:41:39PM +0100, Anselm R Garbe wrote:
On 18 November 2014 19:25, Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the install target of Makefile)?
Sorry if the answer is obvious. I am trying to learn. Thanks.
--
http://www.fastmail.com - The way an
On Tue, 18 Nov 2014 13:25:06 -0500
Greg Reagle greg.rea...@umbc.edu wrote:
Hello. Is there a particular reason that a combination of cp, mkdir,
and chmod are used rather than the install command, in several suckless
projects (in the install target of Makefile)?
Sorry if the answer is
What about a suckless install and a suckless pkgconfig? Both are bloated in
nature but can be implemented in a very simple way to replace easily the gnu or
bsd implementations
On 18 Nov 2014, at 19:30, FRIGN d...@frign.de wrote:
On Tue, 18 Nov 2014 13:25:06 -0500
Greg Reagle
On Tue, 18 Nov 2014 19:51:10 +0100
pancake panc...@youterm.com wrote:
What about a suckless install and a suckless pkgconfig? Both are bloated in
nature but can be implemented in a very simple way to replace easily the gnu
or bsd implementations
We could discuss install, but there's nothing
pancake wrote:
What about a suckless install and a suckless pkgconfig? Both are
bloated in nature but can be implemented in a very simple way to
replace easily the gnu or bsd implementations
You are aware of pkg-conf?
FRIGN said:
We could discuss install, but there's nothing suckless about pkgconfig.
What is wrong with pkg-config?
--
Dmitrij D. Czarkoff
Just read the src. Last time i saw it ... It was about 38kloc
On 18 Nov 2014, at 20:03, Dmitrij D. Czarkoff czark...@gmail.com wrote:
FRIGN said:
We could discuss install, but there's nothing suckless about pkgconfig.
What is wrong with pkg-config?
--
Dmitrij D. Czarkoff
On Tue, Nov 18, 2014 at 07:51:10PM +0100, pancake wrote:
What about a suckless install and a suckless pkgconfig? Both are bloated in
nature but can be implemented in a very simple way to replace easily the gnu
or bsd implementations
I am planning to add install(1) in sbase. It is used
On 11/18/2014 08:18 PM, pancake wrote:
Just read the src. Last time i saw it ... It was about 38kloc
It also depends on glib, which is at the top of the sucks list.
pancake said:
Just read the src. Last time i saw it ... It was about 38kloc
Wander Nauta said:
It also depends on glib, which is at the top of the sucks list.
I don't care this particular implementation. All I care is the idea of
pkg-config. On OpenBSD there is another implementation, which
nope. it doesnt depends on anything, just libc. but its half a megabyte
of code
On 11/18/2014 08:35 PM, Wander Nauta wrote:
On 11/18/2014 08:18 PM, pancake wrote:
Just read the src. Last time i saw it ... It was about 38kloc
It also depends on glib, which is at the top of the sucks list.
On 11/18/2014 09:16 PM, pancake wrote:
nope. it doesnt depends on anything, just libc. but its half a megabyte
of code
As far as I know, the freedesktop implementation at least depends on
(and bundles) a copy of glib. The BSD implementation probably doesn't.
i have a two line shellscript that can replace 99% use of pkg-config,
because its just grep and
cut with few conditionals. that's why i was proposing to have a suckless
pkg-config. I know
that that suckless tends to prefer people doing static linking or no
linking at all and having
everything
oh. that's why ldd was telling me that there was no glib
--with-internal-glibuse internal glib
On 11/18/2014 09:21 PM, Wander Nauta wrote:
On 11/18/2014 09:16 PM, pancake wrote:
nope. it doesnt depends on anything, just libc. but its half a megabyte
of code
As far as I know, the
pancake said:
I didnt knew that pkg-conf thing, but perl or 900 lines seems still
too bloated for me.
I agree.
i have a two line shellscript that can replace 99% use of pkg-config,
because its just grep and cut with few conditionals. that's why i was
proposing to have a suckless pkg-config.
pancake said:
oh. that's why ldd was telling me that there was no glib
--with-internal-glibuse internal glib
Nice they didn't bundle glibc and linux kernel as well.
--
Dmitrij D. Czarkoff
Provided that suckless.org does not provide many needed tools, and that
writing suckless code to replace everything that actually needs
replacement takes long, I gather that such suckless pkg-config should
happen. More so if it can replace tools that suck even more, like
GNU autocrap.
Quoth FRIGN on Tue, Nov 18 2014 19:30 +0100:
Well, install doesn't do any magic.
There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
install-ing to a package directory, and (b) isn't this what
POSIX cp -f is for?
On Tue, 18 Nov 2014 15:49:36 -0500
Wolfgang Corcoran-Mathe first.lord.of.t...@gmail.com wrote:
There is this.[1] But if the issue is unlinking a running target,
(a) how often is this an issue, considering one will often be make
install-ing to a package directory, and (b) isn't this what
another anoying thing of pkg-config is that it uses longopt
--libs can be -l
--cflags can be -c
--list-all can be -a
--version can be -v
...
but if we want it to be compatible we should handle the longopt ones :(
the only complicated part is the version number comparison, because
its not just
install does this in a shot, using 'cp' is just a 20% of what install does:
rm - to ensure that the file is not being used
mkdir
cp
chmod
chown
the rm part is important, because otherwise the cp may fail if the
prorgam is running.
also, a useful install target ihave in some programs of me
32 matches
Mail list logo
