Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385588 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2024-06-05 11:59 +0100 |
| Last post | 2024-06-06 22:56 +0000 |
| Articles | 20 on this page of 96 — 15 participants |
Back to article view | Back to comp.lang.c
Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-05 11:59 +0100
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 01:18 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 03:47 +0100
Re: Running an editor from ANSI C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-06 06:40 +0200
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 04:47 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 09:27 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-06 11:07 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 14:34 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-06 13:54 +0000
Re: Running an editor from ANSI C Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-06 15:13 +0100
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 15:35 +0100
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:40 +0000
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-06 12:54 -0700
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 23:43 +0100
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-06 15:55 -0700
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 10:08 +0100
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 02:37 -0700
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:47 +0000
Re: Running an editor from ANSI C Michael S <already5chosen@yahoo.com> - 2024-06-07 14:24 +0300
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 23:57 +0000
Re: Running an editor from ANSI C Michael S <already5chosen@yahoo.com> - 2024-06-08 22:13 +0300
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 22:06 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-09 14:28 +0000
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 07:24 +0000
Re: Running an editor from ANSI C Michael S <already5chosen@yahoo.com> - 2024-06-09 11:36 +0300
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 22:29 +0000
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-08 13:51 -0700
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-09 00:27 +0000
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 07:30 +0000
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-09 14:48 -0700
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 07:29 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 13:57 +0100
Re: Running an editor from ANSI C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-07 19:56 +0200
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 18:10 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 19:52 +0100
Re: Running an editor from ANSI C Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-07 20:08 +0100
Re: Running an editor from ANSI C Ben Bacarisse <ben@bsb.me.uk> - 2024-06-07 20:09 +0100
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-07 20:37 +0000
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 12:39 -0700
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 00:34 +0000
Re: Running an editor from ANSI C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-07 23:35 -0700
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 08:24 +0000
Re: Running an editor from ANSI C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-10 13:28 -0700
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 14:02 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 20:06 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 20:06 +0000
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-07 04:46 +0000
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:36 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 10:13 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-07 11:31 +0200
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:46 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 13:47 +0100
Re: Running an editor from ANSI C James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-07 09:32 -0400
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 23:59 +0000
Re: Running an editor from ANSI C James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-08 01:40 -0400
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 08:21 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 13:43 +0100
Re: Running an editor from ANSI C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-08 12:00 -0700
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 03:30 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 12:32 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-07 16:48 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-07 19:38 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 20:04 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 00:00 +0100
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 00:36 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 12:07 +0100
Re: Running an editor from ANSI C James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-08 01:54 -0400
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 00:32 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 12:23 +0100
Re: Running an editor from ANSI C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 18:07 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 22:01 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-09 17:49 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-10 12:31 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-10 14:12 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-10 14:19 +0100
Re: Running an editor from ANSI C Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-10 18:14 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-10 17:37 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 05:24 +0100
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-11 05:52 +0000
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 09:08 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-12 11:00 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 10:57 +0100
Re: Running an editor from ANSI C Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-12 13:43 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-12 14:54 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 15:42 +0100
Re: Running an editor from ANSI C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-12 14:34 -0700
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 23:45 +0100
Re: Running an editor from ANSI C tTh <tth@none.invalid> - 2024-06-12 12:37 +0200
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 12:10 +0100
Re: Running an editor from ANSI C David Brown <david.brown@hesbynett.no> - 2024-06-12 15:04 +0200
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 04:46 +0000
Re: Running an editor from ANSI C BGB <cr88192@gmail.com> - 2024-06-06 00:34 -0500
Re: Running an editor from ANSI C Mikko <mikko.levanto@iki.fi> - 2024-06-06 18:42 +0300
Re: Running an editor from ANSI C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-06 17:08 +0100
Re: Running an editor from ANSI C scott@slp53.sl.home (Scott Lurndal) - 2024-06-06 17:56 +0000
Re: Running an editor from ANSI C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 22:56 +0000
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-05 11:59 +0100 |
| Subject | Running an editor from ANSI C |
| Message-ID | <v3pge7$uf2i$1@dont-email.me> |
I'm writing a shell in pure ANSI C, that oerates on FileSystem XML files. So it's a great amount of fun. The BBXFS shell. Except a real shell runs external programs. Which I have to do to all you to edit text files. Because a shell is no good if you can't edit text files easily, and theres no way of doing that in pure C due to the limitations of stdin. So I just call system with nano. And it works. But it's hardly robust, and I'd like to get this right. Check out the shell at https://github.com/MalcolmMcLean/babyxrc -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-06 01:18 +0000 |
| Message-ID | <v3r2pl$16mtl$1@dont-email.me> |
| In reply to | #385588 |
On Wed, 5 Jun 2024 11:59:19 +0100, Malcolm McLean wrote: > So I just call system with nano. The trouble with system(3) is it requires a shell as an intermediary, with consequent pitfalls involving command-line parsing. More robust to use posix_spawn(3).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-06 03:47 +0100 |
| Message-ID | <v3r7v8$1b57j$1@dont-email.me> |
| In reply to | #385605 |
On 06/06/2024 02:18, Lawrence D'Oliveiro wrote: > On Wed, 5 Jun 2024 11:59:19 +0100, Malcolm McLean wrote: > >> So I just call system with nano. > > The trouble with system(3) is it requires a shell as an intermediary, with > consequent pitfalls involving command-line parsing. > > More robust to use posix_spawn(3). > The concept is an ANSI C only shell. I can write my own text editor on top of Posix easily enough. But I want to implent an "edit" command so that users can edit files. And you just can't edit files without non-ASCII keys. So at the moment I call system with nano, and it wotks. But it's a clunky solution. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-06-06 06:40 +0200 |
| Message-ID | <v3rek5$1c4i5$1@dont-email.me> |
| In reply to | #385607 |
On 06.06.2024 04:47, Malcolm McLean wrote: >> > The concept is an ANSI C only shell. > > I can write my own text editor on top of Posix easily enough. > But I want to implent an "edit" command so that users can edit files. > > And you just can't edit files without non-ASCII keys. What do you mean here? You certainly can edit files with Vi-like ASCII-key commands (as, for example, some shells do to allow edit their history file). > So at the moment I call system with nano, and it wotks. But it's a > clunky solution. Nano at least relies on some control-keys. (Is that no issue?) There's a couple of professional systems that allow to spawn any editor (that fits basic calling conventions) that suits you, which is a Good Thing. It's IMO generally a good approach to not force folks to use some specific (or even proprietary) editor in context of an application. (Not that this design practice would be widely observable in practice.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-06 04:47 +0000 |
| Message-ID | <v3rf0b$1c5io$2@dont-email.me> |
| In reply to | #385610 |
On Thu, 6 Jun 2024 06:40:36 +0200, Janis Papanagnou wrote: > It's IMO generally a good approach to not force folks to use some > specific (or even proprietary) editor in context of an application. Checking the $EDITOR environment variable is common practice.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-06 09:27 +0100 |
| Message-ID | <v3rrtm$1e6g8$1@dont-email.me> |
| In reply to | #385610 |
On 06/06/2024 05:40, Janis Papanagnou wrote:
> On 06.06.2024 04:47, Malcolm McLean wrote:
>>>
>> The concept is an ANSI C only shell.
>>
>> I can write my own text editor on top of Posix easily enough.
>> But I want to implent an "edit" command so that users can edit files.
>>
>> And you just can't edit files without non-ASCII keys.
>
> What do you mean here? You certainly can edit files with Vi-like
> ASCII-key commands (as, for example, some shells do to allow edit
> their history file).
>
>> So at the moment I call system with nano, and it wotks. But it's a
>> clunky solution.
>
> Nano at least relies on some control-keys. (Is that no issue?)
>
> There's a couple of professional systems that allow to spawn any
> editor (that fits basic calling conventions) that suits you, which
> is a Good Thing. It's IMO generally a good approach to not force
> folks to use some specific (or even proprietary) editor in context
> of an application. (Not that this design practice would be widely
> observable in practice.)
>
> Janis
>
This is the current code for the "edit" command.
else if (!strcmp(command, "edit"))
{
char *exportargs[4];
char *importargs[4];
char buff[1024];
if (argc == 2)
{
char *tempfile = 0;
tempfile = tmpnam(0);
if (tempfile)
{
exportargs[0] = "export";
exportargs[1] = argv[1];
exportargs[2] = tempfile;
exportargs[3] = 0;
export(shell, 3, exportargs);
snprintf(buff, 1024, "%s %s\n", shell->editor, tempfile);
system(buff);
importargs[0] = "import";
importargs[1] = tempfile;
importargs[2] = argv[1];
importargs[3] = 0;
import(shell, 3, importargs);
}
}
}
It does work. But my compiler warns about rmpnam() being deprecated.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-06 11:07 +0200 |
| Message-ID | <v3ru84$1eafb$1@dont-email.me> |
| In reply to | #385616 |
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. I gather you are doing all this for fun, which is great. You have set yourself a challenge with a total disregard for practicality or reality, and are writing this stuff for your own enjoyment. We all need that kind of project at times. But it seems strange to limit yourself to an ancient and impractical language (C89/C90, which you inaccurately call "ANSI C") for "portability" and then worry about compiler-specific warnings. If you want to check if something is /actually/ deprecated or obsolescent, I'd recommend using a good source - such as future C standards (<https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>) or the cppreference.com site <https://en.cppreference.com/w/c/io/tmpnam>. (Of course, tmpnam() does have plenty of potential problems, and for real code, you'd be better off using Windows-specific and/or POSIX-specific functions for this kind of thing. But that would be against your rules.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-06 14:34 +0100 |
| Message-ID | <v3sdt4$1h7v0$1@dont-email.me> |
| In reply to | #385617 |
On 06/06/2024 10:07, David Brown wrote: > 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. > > I gather you are doing all this for fun, which is great. You have set > yourself a challenge with a total disregard for practicality or reality, > and are writing this stuff for your own enjoyment. We all need that > kind of project at times. > > But it seems strange to limit yourself to an ancient and impractical > language (C89/C90, which you inaccurately call "ANSI C") for > "portability" and then worry about compiler-specific warnings. > > If you want to check if something is /actually/ deprecated or > obsolescent, I'd recommend using a good source - such as future C > standards (<https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>) or > the cppreference.com site <https://en.cppreference.com/w/c/io/tmpnam>. > > > (Of course, tmpnam() does have plenty of potential problems, and for > real code, you'd be better off using Windows-specific and/or > POSIX-specific functions for this kind of thing. But that would be > against your rules.) > > > The shell is up and running. It's not fully featured yet. It doesn't have redirection going or pipes. But you can explore directories and import and export files and print them with cat, an move them about with cp, rm, mv. And you can run BabyBasic scripts (currently just MiniBasic, but the plan is to develop). And host operating system commands, And now editing works. It's definitely a functional shell written in pure ANSI C. It's a great project for a C programmer. See if you can compile it and get it to work. It's a shell written in pure portable ANSI C with no dependencies other than the C Standard library. Get the source here. https://github.com/MalcolmMcLean/babyxrc -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-06 13:54 +0000 |
| Message-ID | <Pcj8O.2409$R506.1932@fx36.iad> |
| In reply to | #385617 |
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 - True, but at least one form of it is not thread-safe.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-06-06 15:13 +0100 |
| Message-ID | <v3sg75$1hmum$1@dont-email.me> |
| In reply to | #385622 |
On 06/06/2024 14:54, Scott Lurndal 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 - > > True, but at least one form of it is not thread-safe. > My man page (Linux man-pages 6.04, 2023-03-30) says that both tmpnam and tmpnam_r are deprecated, and you should use mkstemp(3) or tmpfile(3) instead.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-06 15:35 +0100 |
| Message-ID | <v3shg9$1htuf$1@dont-email.me> |
| In reply to | #385623 |
On 06/06/2024 15:13, Richard Harnden wrote: > On 06/06/2024 14:54, Scott Lurndal 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 - >> >> True, but at least one form of it is not thread-safe. >> > > My man page (Linux man-pages 6.04, 2023-03-30) says that both tmpnam and > tmpnam_r are deprecated, and you should use mkstemp(3) or tmpfile(3) > instead. > It doesn't work. The only way I can get the Baby X shell to run nano is to use tmpnam(). I've tried mkstemp insteaad, and I just can't find a way. tmpfile() is a different kind of a function. Only on very constrained systems will it actually write anything to the backing store. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-07 00:40 +0000 |
| Message-ID | <v3tkub$1o860$4@dont-email.me> |
| In reply to | #385624 |
On Thu, 6 Jun 2024 15:35:53 +0100, Malcolm McLean wrote: > The only way I can get the Baby X shell to run nano is to use tmpnam(). > I've tried mkstemp insteaad, and I just can't find a way. mkstemp opens the temporary file, which is not much use if you want to run an external program which requires a filename. To solve the potential race conditions with creating temporary files, I think the right solution is to use mkdtemp(3) instead. That creates and returns the name of a temporary directory. Now you are free to create as many files (and subdirectories) as you like with whatever names you like within that, secure in the knowledge that nobody else can interfere with you.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-06 12:54 -0700 |
| Message-ID | <87o78dzw1a.fsf@nosuchdomain.example.com> |
| In reply to | #385617 |
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.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-06 23:43 +0100 |
| Message-ID | <v3te2i$1ms1q$1@dont-email.me> |
| In reply to | #385643 |
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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-06 15:55 -0700 |
| Message-ID | <87frtpznoa.fsf@nosuchdomain.example.com> |
| In reply to | #385651 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-07 10:08 +0100 |
| Message-ID | <v3uimm$20jte$3@dont-email.me> |
| In reply to | #385653 |
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
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-07 02:37 -0700 |
| Message-ID | <871q59yty1.fsf@nosuchdomain.example.com> |
| In reply to | #385677 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 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?
What? Why would main need an extra parameter?
> 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.
I thought you said that you invoked nano unconditionally (which is of
course not portable to systems that don't have nano installed).
As for portability, I'm not aware of the $EDITOR convention being used
on non-POSIX systems. I suppose there's no real guarantee that, for
example, system("nano filename") will invoke nano on the named file;
different systems could have different command syntax.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-07 10:47 +0000 |
| Message-ID | <v3uogs$21g4g$6@dont-email.me> |
| In reply to | #385682 |
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote: > As for portability, I'm not aware of the $EDITOR convention being used > on non-POSIX systems. Can non-POSIX systems offer anything better? Any worthwhile alternative? No.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-07 14:24 +0300 |
| Message-ID | <20240607142429.0000067b@yahoo.com> |
| In reply to | #385688 |
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote: > > > As for portability, I'm not aware of the $EDITOR convention being > > used on non-POSIX systems. > > Can non-POSIX systems offer anything better? Any worthwhile > alternative? > > No. Yes. The one below is better. ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-07 23:57 +0000 |
| Message-ID | <v406q5$29fla$5@dont-email.me> |
| In reply to | #385692 |
On Fri, 7 Jun 2024 14:24:29 +0300, Michael S wrote: > On Fri, 7 Jun 2024 10:47:57 -0000 (UTC) > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote: >> >> > As for portability, I'm not aware of the $EDITOR convention being >> > used on non-POSIX systems. >> >> Can non-POSIX systems offer anything better? Any worthwhile >> alternative? >> >> No. > > Yes. The one below is better. > ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL); On Windows, that combines the command-line arguments into a single string. Which then has to be teased apart by the receiving program. Assuming the two ends can agree on consistent rules for doing so.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web