adding third party code to device driver
Hi all, I wrote a device driver for a i2c device. There is a software from third party which at this moment cannot be made part of nuttx. I can edit makefiles to include code, but I think this not a right way to do that. What is the way to add code to the driver to make it easier to switch from one version of nuttx to another? Best regards
Re: [VOTE] Apache NuttX 12.3.0 RC0 release
the patch has been backported for RC1 Thanks for reporting it Best regards Alin On Thu, Oct 12, 2023 at 4:07 AM Xiang Xiao wrote: > A recent change limits c++20 requirement to libcxx: > https://github.com/apache/nuttx/pull/10860 > The owner of libcxx decided not to support the build of libcxx by > an old compiler, It's very hard to sync with the last libcxx version, and > keep the support of the old compiler at the same time in the long term. > > > On Thu, Oct 12, 2023 at 7:31 AM Tomek CEDRO wrote: > > > On Thu, Oct 12, 2023 at 12:19 AM Nathan Hartman wrote: > > > On Wed, Oct 11, 2023 at 3:21 PM Tomek CEDRO wrote: > > > > Hello world, > > > > I have encountered a basic esp32:nsh build error in nuttx-12.3.0-RC0 > > > > related to xtensa g++ 8.4.0 compiler: > > > > xtensa-esp32-elf-g++: error: unrecognized command line option > > > > '-std=gnu++20'; did you mean '-std=gnu++2a'? > > > > > > This was changed in d6453cfc3cd4771a5221528cab3056660be4b1e3 (PR # > 8244). > > > > > > See mail thread: > > > https://lists.apache.org/thread/rkq99os8ql28bv1w8fy5mdqwl3h2vp6m > > > > > > The workaround is to set Kconfig CXX_STANDARD to gnu++2a instead of > > gnu++20. > > > > Thank you Nathan :-) > > > > I am following the mailing list and github PRs so I know this was > > recent change to make better compatibility with C++ and this is fine > > to have this support. But this should not happen at the cost of > > standard build setup and/or enforcing specific compilers / versions to > > everyone by default (see inviolables). This probably also impacts > > other platforms/architectures, especially the older ones. I am sure > > this can be fixed easily. > > > > I am sorry for giving my first -1 as I know there are many new > > features and improvements in the RC, but I am afraid if we don't fix > > that compiler problem now then there will be no incentive to do this > > in future. > > > > > > > It would be nice if the build system could automatically detect the > > > compiler version and set this value accordingly and automatically, > > > without a Kconfig. IIRC there are programs in tools that determine > > > compiler options based on the compiler and version. (Can't remember > > > details off the top of my head at the moment.) > > > > Yes that would be perfect! > > > > Quick search shows that people do this in many ways by calling > > compiler with a list of flags and checking return status for each flag > > to see if it is supported. > > > > Current C++ standards supported by GCC and CLANG are listed here: > > https://gcc.gnu.org/projects/cxx-status.html > > https://clang.llvm.org/cxx_status.html > > > > Quote from GCC: > > C++20 Support in GCC > > GCC has experimental support for the latest revision of the C++ > > standard, which was published in 2020. The status of C++20 library > > features is described in the library documentation. > > C++20 features are available since GCC 8. To enable C++20 support, add > > the command-line parameter -std=c++20 (use -std=c++2a in GCC 9 and > > earlier) to your g++ command line. Or, to enable GNU extensions in > > addition to C++20 features, add -std=gnu++20. > > > > Maybe a simple check can be added to a Makefile? > > > > Maybe a C++ support could be added as option that is disabled by > > default (+compiler check)? > > > > > > > > REMARKS: > > > > 1. flock is a new system build dependency. > > > > > > I think documentation needs to be updated? I think not all systems > > > have flock. Is it a Linux-only thing? (Non-BSD?) > > > > Not a big deal I guess :-) As compared to 12.2.1 in order to build > > 12.3.0-RC0 I had to install additional "flock" application. It comes > > from Linux and it is available on FreeBSD. On macOS (BSD) it is not > > part of the base system too and it can be installed with brew. It > > seems to be fairly old commit that fixes parallel build (which I also > > use). Just a notice :-) > > > > > > > https://github.com/apache/nuttx-apps/blob/91a682f11bba1a537bd095cef45f17db57c9e7b9/Make.defs#L157 > > > > > https://github.com/apache/nuttx-apps/commit/f774e8ee7202a61bcf64a93b2f3ddfd240288cf1 > > > > Thank you :-) > > Tomek > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
Re: adding third party code to device driver
I think there was an option to specify custom drivers relative to board level. This should remain third party as long as you go with "CONFIG_ARCH_BOARD_CUSTOM" BOARD_DRIVERS_DIR ?= $(wildcard $(BOARD_DIR)$(DELIM)..$(DELIM)drivers) Personally I never used it that way, but do not see anything that should stop from using it. Best regards, Petro чт, 12 жовт. 2023 р. о 10:26 пише: > Hi all, > > > > I wrote a device driver for a i2c device. > > There is a software from third party which at this moment cannot be made > part of nuttx. > > I can edit makefiles to include code, but I think this not a right way to > do > that. > > What is the way to add code to the driver to make it easier to switch from > one version of nuttx to another? > > > > Best regards > >
execv obsolet ?
#include
#include
#include
#include
#ifdef CONFIG_BUILD_KERNEL
int main(int argc, FAR char *argv[])
#else
int hello_main(int argc, char *argv[])
#endif
{
if (argc < 2)
{
static char * const args[2] =
{
"/bin/ls",
NULL
};
execv(args[0], args);
}
else
{
int i;
for (i = 1; i < argc; i++)
{
static char * const args[3] =
{
"/bin/ls",
NULL,
NULL
};
args[1] = argv[i];
execv(args[0], args);
}
}
return EXIT_SUCCESS;
}
hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined reference
to `execv'
make[1]: *** [Makefile:173: nuttx] Error 1
make: *** [tools/Unix.mk:537: nuttx] Error 2
Re: execv obsolet ?
you need enable CONFIG_LIBC_EXECFUNCS:
https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
tcpipc...@hotmail.com> wrote:
> #include
> #include
> #include
> #include
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "/bin/ls",
> NULL
> };
>
> execv(args[0], args);
> }
>
> else
> {
> int i;
>
> for (i = 1; i < argc; i++)
> {
> static char * const args[3] =
> {
> "/bin/ls",
> NULL,
> NULL
> };
> args[1] = argv[i];
> execv(args[0], args);
> }
> }
> return EXIT_SUCCESS;
> }
>
> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
> reference to `execv'
> make[1]: *** [Makefile:173: nuttx] Error 1
> make: *** [tools/Unix.mk:537: nuttx] Error 2
>
RE: execv obsolet ?
Now compiles 🙂
in theory should show the files got from ls on terminal ?
Builtin Apps:
i2c sh hellonsh
nsh> hello
nsh>
=
#include
#include
#include
#include
#ifdef CONFIG_BUILD_KERNEL
int main(int argc, FAR char *argv[])
#else
int hello_main(int argc, char *argv[])
#endif
{
if (argc < 2)
{
static char * const args[2] =
{
"ls",
NULL
};
execv(args[0], args);
}
De: Xiang Xiao
Enviado: quinta-feira, 12 de outubro de 2023 18:08
Para: dev@nuttx.apache.org
Assunto: Re: execv obsolet ?
you need enable CONFIG_LIBC_EXECFUNCS:
https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
tcpipc...@hotmail.com> wrote:
> #include
> #include
> #include
> #include
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "/bin/ls",
> NULL
> };
>
> execv(args[0], args);
> }
>
> else
> {
> int i;
>
> for (i = 1; i < argc; i++)
> {
> static char * const args[3] =
> {
> "/bin/ls",
> NULL,
> NULL
> };
> args[1] = argv[i];
> execv(args[0], args);
> }
> }
> return EXIT_SUCCESS;
> }
>
> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
> reference to `execv'
> make[1]: *** [Makefile:173: nuttx] Error 1
> make: *** [tools/Unix.mk:537: nuttx] Error 2
>
Re: execv obsolet ?
Hi Miguel,
I suggest you to try first in the Linux.
NuttX should give you the same result ;-)
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> Now compiles 🙂
>
> in theory should show the files got from ls on terminal ?
>
> Builtin Apps:
> i2c sh hellonsh
> nsh> hello
> nsh>
>
> =
>
> #include
> #include
> #include
> #include
>
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "ls",
> NULL
> };
>
> execv(args[0], args);
> }
> De: Xiang Xiao
> Enviado: quinta-feira, 12 de outubro de 2023 18:08
> Para: dev@nuttx.apache.org
> Assunto: Re: execv obsolet ?
>
> you need enable CONFIG_LIBC_EXECFUNCS:
> https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
>
> On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
> tcpipc...@hotmail.com> wrote:
>
>> #include
>> #include
>> #include
>> #include
>>
>> #ifdef CONFIG_BUILD_KERNEL
>> int main(int argc, FAR char *argv[])
>> #else
>> int hello_main(int argc, char *argv[])
>> #endif
>> {
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "/bin/ls",
>> NULL
>> };
>>
>> execv(args[0], args);
>> }
>>
>> else
>> {
>> int i;
>>
>> for (i = 1; i < argc; i++)
>> {
>> static char * const args[3] =
>> {
>> "/bin/ls",
>> NULL,
>> NULL
>> };
>> args[1] = argv[i];
>> execv(args[0], args);
>> }
>> }
>> return EXIT_SUCCESS;
>> }
>>
>> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
>> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
>> reference to `execv'
>> make[1]: *** [Makefile:173: nuttx] Error 1
>> make: *** [tools/Unix.mk:537: nuttx] Error 2
>>
>
RE: execv obsolet ?
yes, i already had done that 1 year ago
ubuntu@DESKTOP-GRCNLV8:~$ nano hello_main.c
ubuntu@DESKTOP-GRCNLV8:~$ gcc hello_main.c -o hello_main
ubuntu@DESKTOP-GRCNLV8:~$ ./hello_main
Executing 1 /bin/ls
Espruino esp kitware-archive.sh.1
nuttxmbedrust esp-adf
RIOT esp-va-sdk kitware-archive.sh.2
tinygo thread-os freertos
a.out esp32_binary_merger lora-modem-abz-1.2.5
tinygo_0.26.0_amd64.deb
blink go lora-modem-abz-1.2.5.zip
zephyr-sdk-0.15.0 embedded-os-beta-esp32c
cmake-3.21.1-Linux-x86_64.sh hello_main loramac-node
zephyr-sdk-0.15.0_linux-x86_64.tar.gz
drogue-device hello_main.c minicom.log
zephyr-sdk-0.15.1_linux-x86_64.tar.gz
embassy kitware-archive.sh mynewt
On linux works
On nuttx not...i tried the path to...but...the problem is where is the path of
ls
"/ls"
if (argc < 2)
{
static char * const args[2] =
{
"/bin/ls",
NULL
};
printf("Executing 1 %s \n", args[0]);
execv(args[0], args);
}
De: Alan C. Assis
Enviado: quinta-feira, 12 de outubro de 2023 18:48
Para: dev@nuttx.apache.org
Assunto: Re: execv obsolet ?
Hi Miguel,
I suggest you to try first in the Linux.
NuttX should give you the same result ;-)
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> Now compiles 🙂
>
> in theory should show the files got from ls on terminal ?
>
> Builtin Apps:
> i2c sh hellonsh
> nsh> hello
> nsh>
>
> =
>
> #include
> #include
> #include
> #include
>
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "ls",
> NULL
> };
>
> execv(args[0], args);
> }
> De: Xiang Xiao
> Enviado: quinta-feira, 12 de outubro de 2023 18:08
> Para: dev@nuttx.apache.org
> Assunto: Re: execv obsolet ?
>
> you need enable CONFIG_LIBC_EXECFUNCS:
> https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
>
> On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
> tcpipc...@hotmail.com> wrote:
>
>> #include
>> #include
>> #include
>> #include
>>
>> #ifdef CONFIG_BUILD_KERNEL
>> int main(int argc, FAR char *argv[])
>> #else
>> int hello_main(int argc, char *argv[])
>> #endif
>> {
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "/bin/ls",
>> NULL
>> };
>>
>> execv(args[0], args);
>> }
>>
>> else
>> {
>> int i;
>>
>> for (i = 1; i < argc; i++)
>> {
>> static char * const args[3] =
>> {
>> "/bin/ls",
>> NULL,
>> NULL
>> };
>> args[1] = argv[i];
>> execv(args[0], args);
>> }
>> }
>> return EXIT_SUCCESS;
>> }
>>
>> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
>> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
>> reference to `execv'
>> make[1]: *** [Makefile:173: nuttx] Error 1
>> make: *** [tools/Unix.mk:537: nuttx] Error 2
>>
>
RE: execv obsolet ?
1 hour ago, not 1 year ago🙂
De: MIGUEL ALEXANDRE WISINTAINER
Enviado: quinta-feira, 12 de outubro de 2023 19:07
Para: dev@nuttx.apache.org
Assunto: RE: execv obsolet ?
yes, i already had done that 1 year ago
ubuntu@DESKTOP-GRCNLV8:~$ nano hello_main.c
ubuntu@DESKTOP-GRCNLV8:~$ gcc hello_main.c -o hello_main
ubuntu@DESKTOP-GRCNLV8:~$ ./hello_main
Executing 1 /bin/ls
Espruino esp kitware-archive.sh.1
nuttxmbedrust esp-adf
RIOT esp-va-sdk kitware-archive.sh.2
tinygo thread-os freertos
a.out esp32_binary_merger lora-modem-abz-1.2.5
tinygo_0.26.0_amd64.deb
blink go lora-modem-abz-1.2.5.zip
zephyr-sdk-0.15.0 embedded-os-beta-esp32c
cmake-3.21.1-Linux-x86_64.sh hello_main loramac-node
zephyr-sdk-0.15.0_linux-x86_64.tar.gz
drogue-device hello_main.c minicom.log
zephyr-sdk-0.15.1_linux-x86_64.tar.gz
embassy kitware-archive.sh mynewt
On linux works
On nuttx not...i tried the path to...but...the problem is where is the path of
ls
"/ls"
if (argc < 2)
{
static char * const args[2] =
{
"/bin/ls",
NULL
};
printf("Executing 1 %s \n", args[0]);
execv(args[0], args);
}
De: Alan C. Assis
Enviado: quinta-feira, 12 de outubro de 2023 18:48
Para: dev@nuttx.apache.org
Assunto: Re: execv obsolet ?
Hi Miguel,
I suggest you to try first in the Linux.
NuttX should give you the same result ;-)
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> Now compiles 🙂
>
> in theory should show the files got from ls on terminal ?
>
> Builtin Apps:
> i2c sh hellonsh
> nsh> hello
> nsh>
>
> =
>
> #include
> #include
> #include
> #include
>
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "ls",
> NULL
> };
>
> execv(args[0], args);
> }
> De: Xiang Xiao
> Enviado: quinta-feira, 12 de outubro de 2023 18:08
> Para: dev@nuttx.apache.org
> Assunto: Re: execv obsolet ?
>
> you need enable CONFIG_LIBC_EXECFUNCS:
> https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
>
> On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
> tcpipc...@hotmail.com> wrote:
>
>> #include
>> #include
>> #include
>> #include
>>
>> #ifdef CONFIG_BUILD_KERNEL
>> int main(int argc, FAR char *argv[])
>> #else
>> int hello_main(int argc, char *argv[])
>> #endif
>> {
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "/bin/ls",
>> NULL
>> };
>>
>> execv(args[0], args);
>> }
>>
>> else
>> {
>> int i;
>>
>> for (i = 1; i < argc; i++)
>> {
>> static char * const args[3] =
>> {
>> "/bin/ls",
>> NULL,
>> NULL
>> };
>> args[1] = argv[i];
>> execv(args[0], args);
>> }
>> }
>> return EXIT_SUCCESS;
>> }
>>
>> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
>> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
>> reference to `execv'
>> make[1]: *** [Makefile:173: nuttx] Error 1
>> make: *** [tools/Unix.mk:537: nuttx] Error 2
>>
>
RE: execv obsolet ?
when have time, test there Alan
De: Alan C. Assis
Enviado: quinta-feira, 12 de outubro de 2023 18:48
Para: dev@nuttx.apache.org
Assunto: Re: execv obsolet ?
Hi Miguel,
I suggest you to try first in the Linux.
NuttX should give you the same result ;-)
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> Now compiles 🙂
>
> in theory should show the files got from ls on terminal ?
>
> Builtin Apps:
> i2c sh hellonsh
> nsh> hello
> nsh>
>
> =
>
> #include
> #include
> #include
> #include
>
>
> #ifdef CONFIG_BUILD_KERNEL
> int main(int argc, FAR char *argv[])
> #else
> int hello_main(int argc, char *argv[])
> #endif
> {
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "ls",
> NULL
> };
>
> execv(args[0], args);
> }
> De: Xiang Xiao
> Enviado: quinta-feira, 12 de outubro de 2023 18:08
> Para: dev@nuttx.apache.org
> Assunto: Re: execv obsolet ?
>
> you need enable CONFIG_LIBC_EXECFUNCS:
> https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
>
> On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
> tcpipc...@hotmail.com> wrote:
>
>> #include
>> #include
>> #include
>> #include
>>
>> #ifdef CONFIG_BUILD_KERNEL
>> int main(int argc, FAR char *argv[])
>> #else
>> int hello_main(int argc, char *argv[])
>> #endif
>> {
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "/bin/ls",
>> NULL
>> };
>>
>> execv(args[0], args);
>> }
>>
>> else
>> {
>> int i;
>>
>> for (i = 1; i < argc; i++)
>> {
>> static char * const args[3] =
>> {
>> "/bin/ls",
>> NULL,
>> NULL
>> };
>> args[1] = argv[i];
>> execv(args[0], args);
>> }
>> }
>> return EXIT_SUCCESS;
>> }
>>
>> hello_main.c:(.text.hello_main+0xe): undefined reference to `execv'
>> xtensa-esp32-elf-ld: hello_main.c:(.text.hello_main+0x20): undefined
>> reference to `execv'
>> make[1]: *** [Makefile:173: nuttx] Error 1
>> make: *** [tools/Unix.mk:537: nuttx] Error 2
>>
>
Re: execv obsolet ?
Ah ok, I tested using the original code with "ls" instead "/bin/ls"
and the result as similar to NuttX: didn't print anything.
I discovered the issue: ls is not a buildin program, you need to call
a builtin program to get it working.
I modified apps/examples/null to print an incentive message !
/
* Name: null_main
/
int main(int argc, char *argv[])
{
printf("We did it, not because it is easy! But because we thought it
was easy!\n");
return 0;
}
And modified hello to call this null application:
int main(int argc, char *argv[])
{
int ret;
if (argc < 2)
{
static char * const args[2] =
{
"null",
NULL
};
ret = execv(args[0], args);
if (ret < 0)
{
printf("Error: execv failed: %d\n", ret);
}
}
}
See the result:
NuttShell (NSH) NuttX-12.3.0-RC0
nsh> ?
help usage: help [-v] []
. cd exitmount source uptime
[ cp false mv testusleep
? cmp helpprintf timexd
alias dirname hexdump pwd true
unalias dd killrm truncate
basenamedmesg ls rmdir uname
break echomkdir set umount
cat execmkrdsleep unset
Builtin Apps:
hellonsh null sh
nsh> hello
We did it, not because it is easy! But because we thought it was easy!
nsh>
Just used the DEBUG to find-out the issue, the debug binary loader
said exactly what was the issue.
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> 1 hour ago, not 1 year ago🙂
>
> De: MIGUEL ALEXANDRE WISINTAINER
> Enviado: quinta-feira, 12 de outubro de 2023 19:07
> Para: dev@nuttx.apache.org
> Assunto: RE: execv obsolet ?
>
> yes, i already had done that 1 year ago
>
> ubuntu@DESKTOP-GRCNLV8:~$ nano hello_main.c
> ubuntu@DESKTOP-GRCNLV8:~$ gcc hello_main.c -o hello_main
> ubuntu@DESKTOP-GRCNLV8:~$ ./hello_main
> Executing 1 /bin/ls
> Espruino esp kitware-archive.sh.1
> nuttxmbedrust esp-adf
> RIOT esp-va-sdk kitware-archive.sh.2
> tinygo thread-os freertos
> a.out esp32_binary_merger lora-modem-abz-1.2.5
> tinygo_0.26.0_amd64.deb
> blink go lora-modem-abz-1.2.5.zip
> zephyr-sdk-0.15.0 embedded-os-beta-esp32c
> cmake-3.21.1-Linux-x86_64.sh hello_main loramac-node
> zephyr-sdk-0.15.0_linux-x86_64.tar.gz
> drogue-device hello_main.c minicom.log
> zephyr-sdk-0.15.1_linux-x86_64.tar.gz
> embassy kitware-archive.sh mynewt
>
> On linux works
>
> On nuttx not...i tried the path to...but...the problem is where is the path
> of ls
>
> "/ls"
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "/bin/ls",
> NULL
> };
> printf("Executing 1 %s \n", args[0]);
> execv(args[0], args);
> }
>
>
> De: Alan C. Assis
> Enviado: quinta-feira, 12 de outubro de 2023 18:48
> Para: dev@nuttx.apache.org
> Assunto: Re: execv obsolet ?
>
> Hi Miguel,
>
> I suggest you to try first in the Linux.
>
> NuttX should give you the same result ;-)
>
> BR,
>
> Alan
>
> On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
>> Now compiles 🙂
>>
>> in theory should show the files got from ls on terminal ?
>>
>> Builtin Apps:
>> i2c sh hellonsh
>> nsh> hello
>> nsh>
>>
>> =
>>
>> #include
>> #include
>> #include
>> #include
>>
>>
>> #ifdef CONFIG_BUILD_KERNEL
>> int main(int argc, FAR char *argv[])
>> #else
>> int hello_main(int argc, char *argv[])
>> #endif
>> {
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "ls",
>> NULL
>> };
>>
>> execv(args[0], args);
>> }
>> De: Xiang Xiao
>> Enviado: quinta-feira, 12 de outubro de 2023 18:08
>> Para: dev@nuttx.apache.org
>> Assunto: Re: execv obsolet ?
>>
>> you need enable CONFIG_LIBC_EXECFUNCS:
>> https://github.com/apache/nuttx/blob/master/libs/libc/unistd/lib_execv.c#L29
>>
>> On Fri, Oct 13, 2023 at 1:59 AM MIGUEL ALEXANDRE WISINTAINER <
>> tcpipc...@hotmail.com> wrote:
>>
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> #ifdef CONFIG_BUILD_KERNEL
>>> int main(int argc, FAR char *argv[])
>>> #else
>>> int hello_main(int argc, char *argv[])
>>> #endif
>>> {
>>>
>>> if (argc < 2)
>>> {
>>> static char * const args[2] =
>>> {
>>> "/bin/ls",
>>> NULL
>>> };
>>>
>>> execv(args[0], args);
>>> }
>>>
>>> else
>>> {
>>> int i;
>>>
>>> for (i = 1; i < argc; i++)
>>> {
>>> static char * c
Re: execv obsolet ?
The execv on Linux also fails when we can an builtin program, try it:
#include
#include
#include
int main(int argc, char *argv[])
{
int ret;
if (argc < 2)
{
static char * const args[2] =
{
"true",
NULL
};
ret = execv(args[0], args);
if (ret < 0)
{
printf("execv failed: %d\n", ret);
}
}
}
The name convention on NuttX is a little bit different from Linux/Unix:
https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html
In NuttX the builtins are the programs that are not internal in
NuttShell itself, but compiled separated and executed in the nsh.
BR,
Alan
On 10/12/23, Alan C. Assis wrote:
> Ah ok, I tested using the original code with "ls" instead "/bin/ls"
> and the result as similar to NuttX: didn't print anything.
>
> I discovered the issue: ls is not a buildin program, you need to call
> a builtin program to get it working.
>
> I modified apps/examples/null to print an incentive message !
>
> /
> * Name: null_main
> /
>
> int main(int argc, char *argv[])
> {
> printf("We did it, not because it is easy! But because we thought it
> was easy!\n");
> return 0;
> }
>
> And modified hello to call this null application:
>
> int main(int argc, char *argv[])
> {
> int ret;
>
> if (argc < 2)
> {
> static char * const args[2] =
> {
> "null",
> NULL
> };
>
> ret = execv(args[0], args);
> if (ret < 0)
> {
> printf("Error: execv failed: %d\n", ret);
> }
> }
> }
>
> See the result:
>
> NuttShell (NSH) NuttX-12.3.0-RC0
> nsh> ?
> help usage: help [-v] []
>
> . cd exitmount source uptime
> [ cp false mv testusleep
> ? cmp helpprintf timexd
> alias dirname hexdump pwd true
> unalias dd killrm truncate
> basenamedmesg ls rmdir uname
> break echomkdir set umount
> cat execmkrdsleep unset
>
> Builtin Apps:
> hellonsh null sh
> nsh> hello
> We did it, not because it is easy! But because we thought it was easy!
> nsh>
>
> Just used the DEBUG to find-out the issue, the debug binary loader
> said exactly what was the issue.
>
> BR,
>
> Alan
>
> On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
>> 1 hour ago, not 1 year ago🙂
>>
>> De: MIGUEL ALEXANDRE WISINTAINER
>> Enviado: quinta-feira, 12 de outubro de 2023 19:07
>> Para: dev@nuttx.apache.org
>> Assunto: RE: execv obsolet ?
>>
>> yes, i already had done that 1 year ago
>>
>> ubuntu@DESKTOP-GRCNLV8:~$ nano hello_main.c
>> ubuntu@DESKTOP-GRCNLV8:~$ gcc hello_main.c -o hello_main
>> ubuntu@DESKTOP-GRCNLV8:~$ ./hello_main
>> Executing 1 /bin/ls
>> Espruino esp kitware-archive.sh.1
>> nuttxmbedrust esp-adf
>> RIOT esp-va-sdk kitware-archive.sh.2
>> tinygo thread-os freertos
>> a.out esp32_binary_merger lora-modem-abz-1.2.5
>> tinygo_0.26.0_amd64.deb
>> blink go
>> lora-modem-abz-1.2.5.zip
>> zephyr-sdk-0.15.0 embedded-os-beta-esp32c
>> cmake-3.21.1-Linux-x86_64.sh hello_main loramac-node
>> zephyr-sdk-0.15.0_linux-x86_64.tar.gz
>> drogue-device hello_main.c minicom.log
>> zephyr-sdk-0.15.1_linux-x86_64.tar.gz
>> embassy kitware-archive.sh mynewt
>>
>> On linux works
>>
>> On nuttx not...i tried the path to...but...the problem is where is the
>> path
>> of ls
>>
>> "/ls"
>>
>> if (argc < 2)
>> {
>> static char * const args[2] =
>> {
>> "/bin/ls",
>> NULL
>> };
>> printf("Executing 1 %s \n", args[0]);
>> execv(args[0], args);
>> }
>>
>>
>> De: Alan C. Assis
>> Enviado: quinta-feira, 12 de outubro de 2023 18:48
>> Para: dev@nuttx.apache.org
>> Assunto: Re: execv obsolet ?
>>
>> Hi Miguel,
>>
>> I suggest you to try first in the Linux.
>>
>> NuttX should give you the same result ;-)
>>
>> BR,
>>
>> Alan
>>
>> On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
>>> Now compiles 🙂
>>>
>>> in theory should show the files got from ls on terminal ?
>>>
>>> Builtin Apps:
>>> i2c sh hellonsh
>>> nsh> hello
>>> nsh>
>>>
>>> =
>>>
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>>
>>> #ifdef CONFIG_BUILD_KERNEL
>>> int main(int argc, FAR char *argv[])
>>> #else
>>> int hello_main(int argc, char *argv[])
>>> #endif
>>> {
>>>
>>> if (argc < 2)
>>> {
>>> static char * co
RE: execv obsolet ?
I can run (execv) i2c from hello 🙂
works!
Now Gustavo can you this TIP to make work the PCA/PCF GPIO extender 🙂
Thanks!
nsh> hello
Executing 1 /bin/i2c
Usage: i2c [arguments]
Where is one of:
Show help : ?
List buses: bus
List devices : dev [OPTIONS]
Read register : get [OPTIONS] []
Dump register : dump [OPTIONS] []
Show help : help
nsh> Write register: set [OPTIONS] []
Verify access : verf [OPTIONS] [] []
Where common "sticky" OPTIONS include:
[-a addr] is the I2C device address (hex). Default: 03 Current: 03
[-b bus] is the I2C bus number (decimal). Default: 0 Current: 0
[-w width] is the data width (8 or 16 decimal). Default: 8 Current: 8
[-s|n], send/don't send start between command and data. Default: -n Current:
-n
[-i|j], Auto increment|don't increment regaddr on repetitions. Default: NO
Current: NO
[-f freq] I2C frequency. Default: 40 Current: 40
Special non-sticky options:
[-r regaddr] is the I2C device register index (hex). Default: not used/sent
NOTES:
o An environment variable like $PATH may be used for any argument.
o Arguments are "sticky". For example, once the I2C address is
specified, that address will be re-used until it is changed.
WARNING:
o The I2C dev command may have bad side effects on your I2C devices.
Use only at your own risk.
nsh> hello
Executing 1 /bin/i2c
Usage: i2c [arguments]
Where is one of:
Show help : ?
List buses: bus
List devices : dev [OPTIONS]
Read register : get [OPTIONS] []
Dump register : dump [OPTIONS] []
Show help : help
nsh> Write register: set [OPTIONS] []
Verify access : verf [OPTIONS] [] []
Where common "sticky" OPTIONS include:
[-a addr] is the I2C device address (hex). Default: 03 Current: 03
[-b bus] is the I2C bus number (decimal). Default: 0 Current: 0
[-w width] is the data width (8 or 16 decimal). Default: 8 Current: 8
[-s|n], send/don't send start between command and data. Default: -n Current:
-n
[-i|j], Auto increment|don't increment regaddr on repetitions. Default: NO
Current: NO
[-f freq] I2C frequency. Default: 40 Current: 40
Special non-sticky options:
[-r regaddr] is the I2C device register index (hex). Default: not used/sent
NOTES:
o An environment variable like $PATH may be used for any argument.
o Arguments are "sticky". For example, once the I2C address is
specified, that address will be re-used until it is changed.
WARNING:
o The I2C dev command may have bad side effects on your I2C devices.
Use only at your own risk.
De: Alan C. Assis
Enviado: quinta-feira, 12 de outubro de 2023 20:05
Para: dev@nuttx.apache.org
Assunto: Re: execv obsolet ?
Ah ok, I tested using the original code with "ls" instead "/bin/ls"
and the result as similar to NuttX: didn't print anything.
I discovered the issue: ls is not a buildin program, you need to call
a builtin program to get it working.
I modified apps/examples/null to print an incentive message !
/
* Name: null_main
/
int main(int argc, char *argv[])
{
printf("We did it, not because it is easy! But because we thought it
was easy!\n");
return 0;
}
And modified hello to call this null application:
int main(int argc, char *argv[])
{
int ret;
if (argc < 2)
{
static char * const args[2] =
{
"null",
NULL
};
ret = execv(args[0], args);
if (ret < 0)
{
printf("Error: execv failed: %d\n", ret);
}
}
}
See the result:
NuttShell (NSH) NuttX-12.3.0-RC0
nsh> ?
help usage: help [-v] []
. cd exitmount source uptime
[ cp false mv testusleep
? cmp helpprintf timexd
alias dirname hexdump pwd true
unalias dd killrm truncate
basenamedmesg ls rmdir uname
break echomkdir set umount
cat execmkrdsleep unset
Builtin Apps:
hellonsh null sh
nsh> hello
We did it, not because it is easy! But because we thought it was easy!
nsh>
Just used the DEBUG to find-out the issue, the debug binary loader
said exactly what was the issue.
BR,
Alan
On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote:
> 1 hour ago, not 1 year ago🙂
>
> De: MIGUEL ALEXANDRE WISINTAINER
> Enviado: quinta-feira, 12 de outubro de 2023 19:07
> Para: dev@nuttx.apache.org
> Assunto: RE: execv obsolet ?
>
> yes, i already had done that 1 year ago
>
> ubuntu@DESKTOP-GRCNLV8:~$ nano hello_main.c
> ubuntu@DESKTOP-GRCNLV8:~$ gcc hello_main.c -o hello_main
> ubuntu@DESKTOP-GRCNLV8:~$ ./hello_m
Re: execv obsolet ?
On 10/12/2023 2:31 PM, MIGUEL ALEXANDRE WISINTAINER wrote: I can run (execv) i2c from hello 🙂 works! Now Gustavo can you this TIP to make work the PCA/PCF GPIO extender 🙂 Thanks! nsh> hello Executing 1 /bin/i2c Usage: i2c [arguments] Where is one of: There are several confusing things here. /bin/i2c is the I2C tool, obviously. How did it get into /bin? Are you using binfs? binfs will allow you to mount a "fake" file system that exposes the so-called "built-in tasks" as executable files of a file system. execv() and friends will only work on executable files. More typically, executable files would be ELF modules in a real file system in FLASH or on and SD card but binfs fakes a compatible environment. ls, one the other hand is not a built-in task. It is not a task at all and can't be executed from execv(). It is an NSH command that can be executed only from the command line. Even if you have binfs, it should not exist under /bin.
RE: execv obsolet ?
well, works using /bin/i2c Like the Unix nsh> help help usage: help [-v] [] . cp exitmkrdset unset [ cmp false mount sleep uptime ? dirname fdinfo mv source usleep alias dd freepidof testxd unalias df helpprintf time basenamedmesg hexdump ps true break echokillpwd truncate cat env ls rm uname cd execmkdir rmdir umount Builtin Apps: i2c sh hellonsh nsh> nsh> hello Executing 1 /bin/i2c Usage: i2c [arguments] Where is one of: Show help : ? List buses: bus List devices : dev [OPTIONS] Read register : get [OPTIONS] [] Dump register : dump [OPTIONS] [] Show help : help nsh> Write register: set [OPTIONS] [] Verify access : verf [OPTIONS] [] [] Where common "sticky" OPTIONS include: [-a addr] is the I2C device address (hex). Default: 03 Current: 03 [-b bus] is the I2C bus number (decimal). Default: 0 Current: 0 [-w width] is the data width (8 or 16 decimal). Default: 8 Current: 8 [-s|n], send/don't send start between command and data. Default: -n Current: -n [-i|j], Auto increment|don't increment regaddr on repetitions. Default: NO Current: NO [-f freq] I2C frequency. Default: 40 Current: 40 Special non-sticky options: [-r regaddr] is the I2C device register index (hex). Default: not used/sent NOTES: o An environment variable like $PATH may be used for any argument. o Arguments are "sticky". For example, once the I2C address is specified, that address will be re-used until it is changed. WARNING: o The I2C dev command may have bad side effects on your I2C devices. Use only at your own risk. nsh> De: Gregory Nutt Enviado: quinta-feira, 12 de outubro de 2023 20:51 Para: dev@nuttx.apache.org Assunto: Re: execv obsolet ? On 10/12/2023 2:31 PM, MIGUEL ALEXANDRE WISINTAINER wrote: > I can run (execv) i2c from hello 🙂 > > works! > > Now Gustavo can you this TIP to make work the PCA/PCF GPIO extender 🙂 > > Thanks! > > nsh> hello > Executing 1 /bin/i2c > Usage: i2c [arguments] > Where is one of: There are several confusing things here. /bin/i2c is the I2C tool, obviously. How did it get into /bin? Are you using binfs? binfs will allow you to mount a "fake" file system that exposes the so-called "built-in tasks" as executable files of a file system. execv() and friends will only work on executable files. More typically, executable files would be ELF modules in a real file system in FLASH or on and SD card but binfs fakes a compatible environment. ls, one the other hand is not a built-in task. It is not a task at all and can't be executed from execv(). It is an NSH command that can be executed only from the command line. Even if you have binfs, it should not exist under /bin.
RE: execv obsolet ?
i just compiled i2c tools first... De: Gregory Nutt Enviado: quinta-feira, 12 de outubro de 2023 20:51 Para: dev@nuttx.apache.org Assunto: Re: execv obsolet ? On 10/12/2023 2:31 PM, MIGUEL ALEXANDRE WISINTAINER wrote: > I can run (execv) i2c from hello 🙂 > > works! > > Now Gustavo can you this TIP to make work the PCA/PCF GPIO extender 🙂 > > Thanks! > > nsh> hello > Executing 1 /bin/i2c > Usage: i2c [arguments] > Where is one of: There are several confusing things here. /bin/i2c is the I2C tool, obviously. How did it get into /bin? Are you using binfs? binfs will allow you to mount a "fake" file system that exposes the so-called "built-in tasks" as executable files of a file system. execv() and friends will only work on executable files. More typically, executable files would be ELF modules in a real file system in FLASH or on and SD card but binfs fakes a compatible environment. ls, one the other hand is not a built-in task. It is not a task at all and can't be executed from execv(). It is an NSH command that can be executed only from the command line. Even if you have binfs, it should not exist under /bin.
Re: execv obsolet ?
On 10/12/2023 2:05 PM, Alan C. Assis wrote: Ah ok, I tested using the original code with "ls" instead "/bin/ls" and the result as similar to NuttX: didn't print anything. That is a different problem; it did not find ls. On linux, use /execvp/ instead of /execv //or //execve/. With execve, you need to provide the full path to the executable. Otherwise is won't find ls.
Re: execv obsolet ?
On 10/12/2023 2:18 PM, Alan C. Assis wrote: The execv on Linux also fails when we can an builtin program, try it: You are right, but the semantics are really confusing. In Bash, commands that are included inside of Bash are called built-in commands and you cannot execute them. We ignore that naming in NuttX because it onflicts with some historical naming in NuttX: Historically, external commands that are NOT part of NSH are called built-in tasks. You can execv them if they are in binfs (only). But you still can't execv the commands like ls that are a part of NSH.
RE: execv obsolet ?
thank you Gregory De: Gregory Nutt Enviado: quinta-feira, 12 de outubro de 2023 21:06 Para: dev@nuttx.apache.org Assunto: Re: execv obsolet ? On 10/12/2023 2:18 PM, Alan C. Assis wrote: > The execv on Linux also fails when we can an builtin program, try it: You are right, but the semantics are really confusing. In Bash, commands that are included inside of Bash are called built-in commands and you cannot execute them. We ignore that naming in NuttX because it onflicts with some historical naming in NuttX: Historically, external commands that are NOT part of NSH are called built-in tasks. You can execv them if they are in binfs (only). But you still can't execv the commands like ls that are a part of NSH.
Re: execv obsolet ?
Hi Greg, On 10/12/23, Gregory Nutt wrote: > > On 10/12/2023 2:18 PM, Alan C. Assis wrote: >> The execv on Linux also fails when we can an builtin program, try it: > > You are right, but the semantics are really confusing. In Bash, > commands that are included inside of Bash are called built-in commands > and you cannot execute them. We ignore that naming in NuttX because it > onflicts with some historical naming in NuttX: > > Historically, external commands that are NOT part of NSH are called > built-in tasks. You can execv them if they are in binfs (only). But > you still can't execv the commands like ls that are a part of NSH. > Thanks for further explanation! Yes, the naming is confusing, but I think it is difficult to find a better name to those commands that are internal of nsh. At this point calling them built-in like in Linux will make things more confuse because the "external" apps are already called built-in. It is something that everyone using NuttX get grasped too fast. BR, Alan
Re: execv obsolet ?
Some idea how to capture the data returned by exec ? Enviado do meu iPhone > Em 12 de out. de 2023, à(s) 18:16, Alan C. Assis escreveu: > > Hi Greg, > >> On 10/12/23, Gregory Nutt wrote: >> >>> On 10/12/2023 2:18 PM, Alan C. Assis wrote: >>> The execv on Linux also fails when we can an builtin program, try it: >> >> You are right, but the semantics are really confusing. In Bash, >> commands that are included inside of Bash are called built-in commands >> and you cannot execute them. We ignore that naming in NuttX because it >> onflicts with some historical naming in NuttX: >> >> Historically, external commands that are NOT part of NSH are called >> built-in tasks. You can execv them if they are in binfs (only). But >> you still can't execv the commands like ls that are a part of NSH. >> > > Thanks for further explanation! > > Yes, the naming is confusing, but I think it is difficult to find a > better name to those commands that are internal of nsh. At this point > calling them built-in like in Linux will make things more confuse > because the "external" apps are already called built-in. > > It is something that everyone using NuttX get grasped too fast. > > BR, > > Alan
Re: execv obsolet ?
On 10/12/2023 3:26 PM, MIGUEL ALEXANDRE WISINTAINER wrote: Some idea how to capture the data returned by exec ? exec does really return any data other than an int status code which only indicates if the task was correctly started. If you want some text output, you would have to add instrumentation to the code of the task that is being started. It should, for example, inherit stdout so printf() should work.
Re: execv obsolet ?
Here is some history and justification for the naming. Uros Platise created the built-in tasks in 2012 and provided the naming. I would have preferred another name to avoid the conflicts. The meaning of external only makes sense with respect what is internal. If you are think from the perspective of Bash, then internal is what is inside of Bash and external is what is outside of Bash, specifically in a file system. If you are thinking about the whole FLASH image then what is internal is what is in the FLASH and external is what is outside of the FLASH, i.e., on a file system. Uros was replacing file system tasks with internal flash tasks so from his point of view, the FLASH based tasks were internal (or built-in) and not external (on a file system). On 10/12/2023 3:16 PM, Alan C. Assis wrote: Hi Greg, On 10/12/23, Gregory Nutt wrote: On 10/12/2023 2:18 PM, Alan C. Assis wrote: The execv on Linux also fails when we can an builtin program, try it: You are right, but the semantics are really confusing. In Bash, commands that are included inside of Bash are called built-in commands and you cannot execute them. We ignore that naming in NuttX because it onflicts with some historical naming in NuttX: Historically, external commands that are NOT part of NSH are called built-in tasks. You can execv them if they are in binfs (only). But you still can't execv the commands like ls that are a part of NSH. Thanks for further explanation! Yes, the naming is confusing, but I think it is difficult to find a better name to those commands that are internal of nsh. At this point calling them built-in like in Linux will make things more confuse because the "external" apps are already called built-in. It is something that everyone using NuttX get grasped too fast. BR, Alan
Re: execv obsolet ?
Did you try popen() ? https://stackoverflow.com/questions/43116/how-can-i-run-an-external-program-from-c-and-parse-its-output Look the example at apps/examples/popen BR, Alan On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote: > Some idea how to capture the data returned by exec ? > > Enviado do meu iPhone > >> Em 12 de out. de 2023, à(s) 18:16, Alan C. Assis >> escreveu: >> >> Hi Greg, >> >>> On 10/12/23, Gregory Nutt wrote: >>> On 10/12/2023 2:18 PM, Alan C. Assis wrote: The execv on Linux also fails when we can an builtin program, try it: >>> >>> You are right, but the semantics are really confusing. In Bash, >>> commands that are included inside of Bash are called built-in commands >>> and you cannot execute them. We ignore that naming in NuttX because it >>> onflicts with some historical naming in NuttX: >>> >>> Historically, external commands that are NOT part of NSH are called >>> built-in tasks. You can execv them if they are in binfs (only). But >>> you still can't execv the commands like ls that are a part of NSH. >>> >> >> Thanks for further explanation! >> >> Yes, the naming is confusing, but I think it is difficult to find a >> better name to those commands that are internal of nsh. At this point >> calling them built-in like in Linux will make things more confuse >> because the "external" apps are already called built-in. >> >> It is something that everyone using NuttX get grasped too fast. >> >> BR, >> >> Alan >
Re: execv obsolet ?
Wow! Maybe sprintf, right ? Enviado do meu iPhone > Em 12 de out. de 2023, à(s) 18:31, Gregory Nutt > escreveu: > > >> On 10/12/2023 3:26 PM, MIGUEL ALEXANDRE WISINTAINER wrote: >> Some idea how to capture the data returned by exec ? > > exec does really return any data other than an int status code which only > indicates if the task was correctly started. > > If you want some text output, you would have to add instrumentation to the > code of the task that is being started. It should, for example, inherit > stdout so printf() should work. >
Re: execv obsolet ?
I will test too soon, well, gustavo can do it :) Enviado do meu iPhone > Em 12 de out. de 2023, à(s) 19:22, Alan C. Assis escreveu: > > Did you try popen() ? > > https://stackoverflow.com/questions/43116/how-can-i-run-an-external-program-from-c-and-parse-its-output > > Look the example at apps/examples/popen > > BR, > > Alan > >> On 10/12/23, MIGUEL ALEXANDRE WISINTAINER wrote: >> Some idea how to capture the data returned by exec ? >> >> Enviado do meu iPhone >> >>> Em 12 de out. de 2023, à(s) 18:16, Alan C. Assis >>> escreveu: >>> >>> Hi Greg, >>> On 10/12/23, Gregory Nutt wrote: > On 10/12/2023 2:18 PM, Alan C. Assis wrote: > The execv on Linux also fails when we can an builtin program, try it: You are right, but the semantics are really confusing. In Bash, commands that are included inside of Bash are called built-in commands and you cannot execute them. We ignore that naming in NuttX because it onflicts with some historical naming in NuttX: Historically, external commands that are NOT part of NSH are called built-in tasks. You can execv them if they are in binfs (only). But you still can't execv the commands like ls that are a part of NSH. >>> >>> Thanks for further explanation! >>> >>> Yes, the naming is confusing, but I think it is difficult to find a >>> better name to those commands that are internal of nsh. At this point >>> calling them built-in like in Linux will make things more confuse >>> because the "external" apps are already called built-in. >>> >>> It is something that everyone using NuttX get grasped too fast. >>> >>> BR, >>> >>> Alan >>
Re: [VOTE] Apache NuttX 12.3.0 RC0 release
On Thu, Oct 12, 2023 at 9:52 AM Alin Jerpelea wrote: > the patch has been backported for RC1 > Thanks for reporting it > Best regards > Alin Perfect! Thank you Alin! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
