Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Running an editor from ANSI C
Date: Thu, 06 Jun 2024 15:55:33 -0700
Organization: None to speak of
Lines: 58
Message-ID: <87frtpznoa.fsf@nosuchdomain.example.com>
References: <v3pge7$uf2i$1@dont-email.me> <v3r2pl$16mtl$1@dont-email.me>
	<v3r7v8$1b57j$1@dont-email.me> <v3rek5$1c4i5$1@dont-email.me>
	<v3rrtm$1e6g8$1@dont-email.me> <v3ru84$1eafb$1@dont-email.me>
	<87o78dzw1a.fsf@nosuchdomain.example.com>
	<v3te2i$1ms1q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 07 Jun 2024 00:55:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3ec284f1a7e8071e4d0b56ae14cf643f";
	logging-data="1789942"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19OW+9f5KZPAPw4RbM4a0mt"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:W+vVhZZTr7GZU4MdE6xnRg6nblA=
	sha1:O24OPjSV8p14apKeTFTH314RJWc=
Bytes: 4136

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 06/06/2024 20:54, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 06/06/2024 10:27, Malcolm McLean wrote:
>>>> It does work. But my compiler warns about rmpnam() being deprecated.
>>>
>>> I presume you mean "tmpnam()" here.  No, it has not been deprecated -
>>> not even in C23.  I could be wrong, but this sounds like one of MSVC's
>>> arbitrary self-declared deprecations, using scare tactics to encourage
>>> people to use MSVC's own functions rather than standard C functions,
>>> thus locking you into their tools and platform.
>> [...]
>> You're right, tmpnam() is not deprecated either by ISO C or by
>> POSIX.
>> But tmpfile() is likely to be better for most purposes.  It creates
>> a
>> file and returns a FILE*.  tmpnam() returns a string pointer, and it's
>> possible that some other process could create a file with the same name
>> before the caller has a chance to create it.
>> (mkstemp() is more flexible, but is not defined by ISO C.)
>> 
> I want to run nano (or vi, or ed), in a shell running a pure ansi C
> program. So the way to do it is to create a file, write the text you
> want edit to it, them call system("nano readme.txt"). Nano then grabs 
> the  cobsole, which is what you want. You then read the file to get
> the edited data.
>
> The shell isn't just a proof og concept. It has a practical purpose,
> because it is FileSystem XML file editor. Whilst I'm playing about 
> putting Basic into it for fun, the real purpose is serious. And the
> user must have an easy way of editing text files in the FileSystem
> file.
>
> But it becomes effectively a virtual computer in its own right.

OK -- but that has nothing at all to do with my post, which was about
how to generate the temporary file name.

One suggestion: rather than always using nano (which not everyone is
familiar with), try reading the $EDITOR environment variable to
determine what editor to use.  Concatenating the value of
getenv("EDITOR"), followed by a space, followed by the file name, is
likely to give you a valid command you can pass to system().  Fall back
to nano if getenv("EDITOR") returns a null pointer.

(For historical reasons, the convention is to use $VISUAL if it's set,
otherwise $EDITOR if it's set, otherwise some default.  Originally
$VISUAL typically referred to a full-screen editor like vi and $EDITOR
to a line editor like ed, to be used when full-screen editing is not
available.  That's unlikely to be relevant nowadays, and users typically
either don't set $VISUAL or set it to the same thing as $EDITOR.)

Don't do this for me; I'm not likely to use this.  But others are likely
to find it more user-friendly if they can use a chosen editor.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */