Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Running an editor from ANSI C
Date: Fri, 7 Jun 2024 10:08:38 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <v3uimm$20jte$3@dont-email.me>
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>
 <87frtpznoa.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 07 Jun 2024 11:08:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bbc6ce194fadee025562548db60d9fc6";
	logging-data="2117550"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Sr4UEBkv7TzA5UL1Migt1SKSI5D1S3+0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:CkV5gO+f1z85dAf58PX0rDRrE0E=
Content-Language: en-GB
In-Reply-To: <87frtpznoa.fsf@nosuchdomain.example.com>
Bytes: 4629

On 06/06/2024 23:55, Keith Thompson wrote:
> 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.
>


Ah thank you. But then main has to take an extra parameter. Now  will 
the shell still be absolutely robust, and completely portable, and run 
just anywhere?

THe user of course calls the shell with an option to specify an editor. 
But $EDITOR should be the default. I'm not the first person to do this.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm