From: Andreas Ericsson <ae@op5.se>
To: git@vger.kernel.org
Subject: Re: [PATCH 1/3] C implementation of the 'git' program, take two.
Date: Wed, 16 Nov 2005 01:10:36 +0100 [thread overview]
Message-ID: <437A78FC.10608@op5.se> (raw)
In-Reply-To: <7vwtj9eaqm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> exon@op5.se (Andreas Ericsson) writes:
>
>
>>This patch provides a C implementation of the 'git' program and
>>introduces support for putting the git-* commands in a directory
>>of their own.
>
>
> Very nice, thanks. Two questions and a half.
>
>
>>+static void prepend_to_path(const char *dir, int len)
>>+{
>>+ char *path, *old_path = getenv("PATH");
>>+ int path_len = len;
>>+
>>+ if (!old_path)
>>+ old_path = "/bin:/usr/bin:.";
>
>
> This is to cover strange case and probably would not matter in
> practice, but perhaps without current directory?
>
I have no preference really and since it already covers a strange case
it probably shouldn't matter either way.
>
>>+int main(int argc, char **argv, char **envp)
>>+{
>>+ char git_command[PATH_MAX + 1];
>>+ char wd[PATH_MAX + 1];
>>+ int i, len, show_help = 0;
>>+ char *exec_path = getenv("GIT_EXEC_PATH");
>>+
>>+ getcwd(wd, PATH_MAX);
>>+...
>>+ /* allow relative paths, but run with exact */
>>+ if (chdir(exec_path)) {
>>+ printf("git: '%s': %s\n", exec_path, strerror(errno));
>>+ exit (1);
>>+ }
>>+
>>+ getcwd(git_command, sizeof(git_command));
>>+ chdir(wd);
>
>
> Can we always come back from where we started?
>
Not sure what you mean. Perhaps "Come back *to* where we started"?
If getcwd(wd, sizeof(wd)) fails then chdir(wd) will also fail (or do
something strange, at least). wd is otherwise absolute.
>
>>+
>>+ len = strlen(git_command);
>>+ prepend_to_path(git_command, len);
>>+
>>+ strncat(&git_command[len], "/git-", sizeof(git_command) - len);
>>+ len += 5;
>>+ strncat(&git_command[len], argv[i], sizeof(git_command) - len);
>>+
>>+ if (access(git_command, X_OK))
>>+ usage(exec_path, "'%s' is not a git-command", argv[i]);
>>+
>>+ /* execve() can only ever return if it fails */
>>+ execve(git_command, &argv[i], envp);
>
>
> Shell version for Cygwin seems to do ".exe" at the end --- does
> it matter?
>
Dunno, really. I suppose it does as it bypasses the shell with the
execve() call, unless windows or the cygwin stuff does some trickery to
find an .exe regardless.
Is it ok if I send a separate patch for it, or would you rather have me
redo this one?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2005-11-16 0:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 23:31 [PATCH 1/3] C implementation of the 'git' program, take two Andreas Ericsson
2005-11-15 23:45 ` Junio C Hamano
2005-11-16 0:10 ` Andreas Ericsson [this message]
2005-11-16 0:17 ` Junio C Hamano
2005-11-16 0:18 ` Linus Torvalds
2005-11-16 0:42 ` Andreas Ericsson
2005-11-16 2:02 ` Linus Torvalds
2005-11-16 2:18 ` Johannes Schindelin
2005-11-16 21:04 ` Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437A78FC.10608@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).