Re: unlink utility

2014-03-27 Thread Marc Espie
On Wed, Mar 26, 2014 at 06:25:16PM +0100, Dmitrij Czarkoff wrote:
> Theo de Raadt wrote:
> >
> > > but given that 'unlink' is already used in some scripts
> >
> > I would like to see some proof of that.
> 
> The use that triggered my original mail was in tests for devel/py-dulwich.

Oh, python code. not surprised... ;p



Re: unlink utility

2014-03-26 Thread Dmitrij Czarkoff
Theo de Raadt wrote:
>
> Perhaps you can push upstream to use the better tools?

I did, and I always do so.
--
Dmitrij D. Czarkoff



Re: unlink utility

2014-03-26 Thread Theo de Raadt
> > > but given that 'unlink' is already used in some scripts
> >
> > I would like to see some proof of that.
> 
> The use that triggered my original mail was in tests for devel/py-dulwich.

Perhaps you can push upstream to use the better tools?

How long before we find clri being used?



Re: unlink utility

2014-03-26 Thread Dmitrij Czarkoff
Theo de Raadt wrote:
>
> > but given that 'unlink' is already used in some scripts
>
> I would like to see some proof of that.

The use that triggered my original mail was in tests for devel/py-dulwich.

And I am quite sure I've seen it elsewhere recently, but I have no proof
for that.

P.S.: Apparently there is another patch to remove 'unlink' in ports - in
sysutils/gitolite. Thankfully this appears to come from upstream.

--
Dmitrij D. Czarkoff



Re: unlink utility

2014-03-26 Thread Jérémie Courrèges-Anglas
Theo de Raadt  writes:

>> but given that 'unlink' is already used in some scripts
>
> I would like to see some proof of that.
>
> The way I see it, the ports tree is a large enough ecosystem capable
> of measuring whether something is in use.
>
> So, since it isn't in the ports tree, please show some proof.

The only port that we patch so that it calls rm -f instead of unlink at
runtime is sysutils/gitolite.  The patch has already been committed
upstream.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: unlink utility

2014-03-26 Thread Jérémie Courrèges-Anglas
"Dmitrij D. Czarkoff"  writes:

> Gilles Chehade said:
>> without commenting on the need for the utility itself, the code you have
>> provided does not respect the coding style of OpenBSD, and your main
>> function shouldn't be returning errno
>
> Sorry, I was not paying enough attention to style.

Not discussing the usefulness of unlink(1), but it's bikeshedding time
here.  Sorry. :)

> What about this one:
>
> 
>  unlink.c
> 
> /*
>  * Copyright (c) 2014 Dmitrij D. Czarkoff 
>  *
>  * Permission to use, copy, modify, and distribute this software for any
>  * purpose with or without fee is hereby granted, provided that the above
>  * copyright notice and this permission notice appear in all copies.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
>  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  */
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> extern char   *__progname;
>
> static void   usage(void);
>
> int
> main(int argc, char **argv)
> {
>   setlocale(LC_ALL, "");
>
>   if (argc != 2)
>   usage();

I suggest using getopt() and the usual "argc -= optind, argv += optind"
dance, for consistency at the source level and to handle "--"
transparently.

>   else if (unlink(*(argv + 1))) {

With what I said above, this becomes "*argv".

>   perror(__progname);
>   return (1);

err() can do this in one line, while giving you a more rich error message:

err(1, "unable to delete `%s'", *argv);

>   }
>   return (0);
> }
>
> static void
> usage(void)
> {
>   (void)fprintf(stderr, "usage: %s file\n", __progname);

Now that we have getprogname(), maybe we could start using it?

>   exit(1);
> }
> 

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: unlink utility

2014-03-26 Thread Tony Abernethy
Ted Unangst wrote
> Sometimes I think refusing to implement stupid standards is the only
> way to fight back.

Thank you.
For such as this I lurk on this list, 
not for help with OpenBSD, 
but for help with everything else.

Something OpenBSD does get right.
Good Stuff is not made from more of Bad Stuff.



Re: unlink utility

2014-03-26 Thread Theo de Raadt
> but given that 'unlink' is already used in some scripts

I would like to see some proof of that.

The way I see it, the ports tree is a large enough ecosystem capable
of measuring whether something is in use.

So, since it isn't in the ports tree, please show some proof.



Re: unlink utility

2014-03-26 Thread Patrick Lamaiziere
Le Wed, 26 Mar 2014 12:19:25 +0100,
"Dmitrij D. Czarkoff"  a écrit :

Hello,

> For some reason POSIX X/Open Systems Interfaces option requires
> 'unlink' utility to be present in operating system.  Sure, it does
> nothing that 'rm' doesn't already do, but given that 'unlink' is
> already used in some scripts, I wonder if it would be benefitial for
> OpenBSD to include such utility.
> 
> FWIW a simple implementation follows.

On FreeBSD /bin/unlink is a link to /bin/rm 

/*
 * Test for the special case where the utility is called as
 * "unlink", for which the functionality provided is greatly
 * simplified.
 */
if ((p = strrchr(argv[0], '/')) == NULL)
p = argv[0];
else
++p;
if (strcmp(p, "unlink") == 0) {
while (getopt(argc, argv, "") != -1)
usage();
argc -= optind;
argv += optind;
if (argc != 1)
usage();
rm_file(&argv[0]);
exit(eval);
}

>   } else if (unlink(*(argv+1))) {

Hmm the code in rm does more than a simple unlink(2).

Regards,



Re: unlink utility

2014-03-26 Thread Dmitrij D. Czarkoff
Gilles Chehade said:
> without commenting on the need for the utility itself, the code you have
> provided does not respect the coding style of OpenBSD, and your main
> function shouldn't be returning errno

Sorry, I was not paying enough attention to style.

What about this one:


 unlink.c

/*
 * Copyright (c) 2014 Dmitrij D. Czarkoff 
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

#include 
#include 
#include 
#include 
#include 

extern char *__progname;

static void usage(void);

int
main(int argc, char **argv)
{
setlocale(LC_ALL, "");

if (argc != 2)
usage();
else if (unlink(*(argv + 1))) {
perror(__progname);
return (1);
}
return (0);
}

static void
usage(void)
{
(void)fprintf(stderr, "usage: %s file\n", __progname);
exit(1);
}


-- 
Dmitrij D. Czarkoff



Re: unlink utility

2014-03-26 Thread Ted Unangst
On Wed, Mar 26, 2014 at 12:19, Dmitrij D. Czarkoff wrote:
> For some reason POSIX X/Open Systems Interfaces option requires 'unlink'
> utility to be present in operating system.  Sure, it does nothing that

With no rationale given. :(

> 'rm' doesn't already do, but given that 'unlink' is already used in some
> scripts, I wonder if it would be benefitial for OpenBSD to include such
> utility.

Sometimes I think refusing to implement stupid standards is the only
way to fight back.



Re: unlink utility

2014-03-26 Thread Gilles Chehade

Hello,

without commenting on the need for the utility itself, the code you have
provided does not respect the coding style of OpenBSD, and your main
function shouldn't be returning errno

Gilles

On 03/26/14 12:19, Dmitrij D. Czarkoff wrote:

Hello!

For some reason POSIX X/Open Systems Interfaces option requires 'unlink'
utility to be present in operating system.  Sure, it does nothing that
'rm' doesn't already do, but given that 'unlink' is already used in some
scripts, I wonder if it would be benefitial for OpenBSD to include such
utility.

FWIW a simple implementation follows.



unlink.c

/*
  * Copyright (c) 2014 Dmitrij D. Czarkoff 
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */

#include 
#include 
#include 
#include 
#include 

extern char *__progname;

void  usage(void);

int
main(int argc, char **argv)
{
setlocale(LC_ALL, "");

   if (argc != 2) {
 usage();
   } else if (unlink(*(argv+1))) {
 perror("unlink");
 return errno;
   }

   return 0;
}


void
usage(void)
{
(void)fprintf(stderr, "usage: %s file\n", __progname);
exit(1);
}



unlink.1

.\"
.\" Copyright (c) 2014 Dmitrij D. Czarkoff 
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $Mdocdate: March 26 2014 $
.Dt UNLINK 1
.Os
.Sh NAME
.Nm unlink
.Nd call the
.Xr unlink 2
function
.Sh SYNOPSIS
.Nm unlink
.Ar file
.Sh DESCRIPTION
The
.Nm
utility calls
.Xr unlink 2
function to remove a
.Ar file
specified on the command line.
.Pp
A user may need appropriate privileges to invoke the
.Nm
utility.
.Sh EXIT STATUS
.Ex -std unlink
.Sh SEE ALSO
.Xr link 1,
.Xr rm 1 ,
.Xr unlink 2
.Sh STANDARDS
The
.Nm
utility is compliant with the
.St -p1003.1-2008
specification.
.Sh HISTORY
The
.Nm
utility first appeared in
.Ox 5.6 .