10

Several users are associating the tag (244 questions) with Find's -exec option. Find && Exec tagged questions amounts to almost the half of that value (105 questions). The tag's description, however, does not include that meaning:

The exec() family of functions replaces the current process image with a new process image, retaining the pid and pipes of the old process. This tag is also used for the shell built-in which can be used to replace the current shell with a program or various redirection-related stuff.

Should we remove the tag where its usage is inappropriate or would it be preferable to include that meaning to the tag?

11
  • 11
    IMO, any question relating to -exec should be tagged with find, not exec. It would be appropriate to correct questions with the wrong sets of tags. If this is best done in bulk or a bit every now and again, I don't know. – Kusalananda Mar 12 at 20:33
  • 2
    The only thing I'm concerned about with regards to bulk edits is that it pushes new questions off the front page if too many are done at once. – Kusalananda Mar 12 at 20:42
  • 1
    Very good point, I had never thought about that. Then by bits should be better lest we drown them. – Quasímodo Mar 12 at 20:44
  • 2
    -exec is the predicate that tells find to use those exec*() system calls (in addition to fork() and wait*() of course), so it's not completely irrelevant. The shell's exec is more a no-fork command, so it's less relevant to exec*() than find's -exec I'd say. – Stéphane Chazelas Mar 13 at 6:45
  • 3
    @StéphaneChazelas Usually, when someone has an issue using -exec with find, it is a find issue (syntax, how to find the wanted things, how to loop over results, etc.), not an exec*() issue. – Kusalananda Mar 13 at 12:05
  • 2
    @Kusalananda, or it's an issue about executing things with find. If the exec tag is already used for the exec special builtin of shell and for the exec*() system calls, we might as well use it for anything that's named exec. I won't argue much more about it, regardless of what it's used for I doubt it will be useful for anything anyway. – Stéphane Chazelas Mar 13 at 13:30
  • Rename exec to something more specific, like exec-syscall or something and done. – Braiam Mar 17 at 8:56
  • @StéphaneChazelas in that case, the exec tag would refer to two things: a find predicate and a system call. Tags are supposed to mean exactly one thing. If we need a tag for the system call, it has to be its own tag. Also, that would mean that any command that executes the exec syscall should use the tag, which would dilute its usefulness. – Braiam Mar 17 at 8:59
  • 5
    It makes very little sense to have any tag that refers to an option. All tags for commands should be for the command itself. – Chenmunka Mar 17 at 10:39
  • In any case, there's no exec() system call. There are some execve(), execv(), execveat() , fexecve() and there are some standard C API functions around those like execl(), execvp()... And some languages including perl/python have some exec function around those. shells' whole raison d'être is to expose that system call to the user. Its own exec builtin is to not do it in a child process (with differences in behaviour between implementation when the command is builtin or a function). find's -exec is also a wrapper around those (though in a child process). – Stéphane Chazelas Mar 25 at 17:09
  • @Chenmunka, -exec is not an option of find, it's a predicate. The options are -H and -L (some implementations have more). -exec is an action predicate in the find language like exec is an action function in the perl language. They are both about executing commands. What we need here is drawing the line as to what exec is meant to be used for. My personal line is "I don't care much, my only usage of tags is for the watch and ignore tag feature, and I can't see how that tag can be useful to anything". – Stéphane Chazelas Mar 25 at 17:31
1

To my mind, the find tag should be for questions with regard to the find command and its invocations (including the -exec and -execdir arguments), uses, permutations, idiosyncracies, and foibles.

Similarly, the exec tag (as currently defined) should be for questions specifically about the system call, its uses, invocations, permutations, and foibles.

If we expand the scope of the tag meant for discussing the exec() system call to include things which just happen to as a consequence of their use invoke the system call, then tagging the system call itself is devoid of all meaning.

As such, I would be inclined to remove the exec tags from such questions where it is present, and add the find tag where it is absent.

5
  • But most of the usages of the exec tag ATM the moment are for that find -exec or the exec builtin of some shells, not the execve() system call or the family of exec*() C library functions (there are some, but they are a minority). Should we retag them and update the tag definition to remove the reference to the shell builtin? Or should we on the other hand extend it to the exec functions of languages other than C (perl, ruby, python, sh, csh, ... find)? – Stéphane Chazelas Mar 25 at 17:02
  • That is a good question, but I believe it to be out of scope of the question at hand ("Is exec a relevant tag for find questions?"). – DopeGhoti Mar 25 at 17:51
  • But your answer currently contradicts the tag definition, and suggests it should be changed to exclude using that tag for the exec sh builtin. – Stéphane Chazelas Mar 25 at 17:53
  • I don't see how the answer ("remove the exec tag from questions about find where it is present, and add the find tag where it is absent) contradicts the definition of the exec tag. Whether the definition of the exec tag should be modified or whether a bash-exec tag should be created is, again, an whole other question. – DopeGhoti Mar 25 at 18:46
  • You're saying should be for questions specifically about the system call, its uses..., the current tag definition says: This tag is also used for the shell built-in which can be used to replace the current shell with a program or various redirection-related stuff. exec 2>&1 is a wrapper around the dup2() system call, not the execve() system call (no Unix-lie system has a exec() system call btw AFAIK). – Stéphane Chazelas Mar 25 at 19:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .