Linux target does not work for 5.3.2, but works in 5.3.1 (IDFGH-14263)

[joyhope]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3.2

Espressif SoC revision.

linux

Operating System used.

Linux

How did you build your project?

Command line with Make

If you are using Windows, please specify command line type.

None

Development Kit.

linux

Power Supply used.

USB

What is the expected behavior?

I make a little change for system/console/basic/ for support linux target. The same application, using v5.3.1 SDK, the console works. waiting for user input, but with 5.3.2 SDK, the console constant work, output "Unrecognized command
". It seem console not block for user input.

What is the actual behavior?

Expect:
``
Type 'help' to get the list of commands.
Use UP/DOWN arrows to navigate through command history.
Press TAB when typing command name to auto-complete.
linux> help
free
Get the current size of free heap memory

heap
Get minimum size of free heap memory that was available during program
execution

The problem v5.3.2 behavior

auto execute output. 

linux>
Unrecognized command

### Steps to reproduce.

system/console/basic 

root cmake file

if("${IDF_TARGET}" STREQUAL "linux")
set(COMPONENTS main)
endif()

cmakefile in main.

set(requires "")
idf_build_get_property(target IDF_TARGET)

if(${target} STREQUAL "linux")
list(APPEND requires esp_stubs esp_event esp-tls esp_http_client console nvs_flash)
endif()

idf_component_register(SRCS "console_example_main.c"
INCLUDE_DIRS "."
REQUIRES ${requires})

Some minor compile problem in console/advanced/ , easy to process. 




### Debug Logs.

_No response_

### More Information.

It is good to support linux target. 

[ESP-Marius]

The console implementation on linux has a known issue, the read() call can be interrupted by the signals, e.g. what the freertos implementation uses for sheduling different threads.

I don't think there is anything different between v5.3.1 and v5.3.2 in this regard, the fact that it worked is probably related to another difference in your project.

Right now it cannot be reliably used on linux, finding a workaround for this issue is in our backlog.

[joyhope]

This is a strange result. I compare the console, esp_vfs_console with two versions. Nothing changed. But in my test case, it works perfectly on v5.3.1. The read is not blocked.

…

On Thu, Dec 19, 2024 at 4:11 PM ESP-Marius ***@***.***> wrote: The console implementation on linux has a known issue, the read() call can be interrupted by the signals, e.g. what the freertos implementation uses for sheduling different threads. I don't think there is anything different between v5.3.1 and v5.3.2 in this regard, the fact that it worked is probably related to another difference in your project. Right now it cannot be reliably used on linux, finding a workaround for this issue is in our backlog. — Reply to this email directly, view it on GitHub <#15056 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4Y6UH6JPY4RDDM2JS7MST2GJ5RZAVCNFSM6AAAAABT4B34EKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJTGAZDQOBSGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[joyhope]

I attached the problem project. If the target is Linux, there is a simple compile error in the components/xxx_cmd. It is easy to process. I am very curious which kind of bug will cause this problem.

…

On Thu, Dec 19, 2024 at 9:32 PM yueyue papa ***@***.***> wrote: This is a strange result. I compare the console, esp_vfs_console with two versions. Nothing changed. But in my test case, it works perfectly on v5.3.1. The read is not blocked. On Thu, Dec 19, 2024 at 4:11 PM ESP-Marius ***@***.***> wrote: > The console implementation on linux has a known issue, the read() call > can be interrupted by the signals, e.g. what the freertos implementation > uses for sheduling different threads. > > I don't think there is anything different between v5.3.1 and v5.3.2 in > this regard, the fact that it worked is probably related to another > difference in your project. > > Right now it cannot be reliably used on linux, finding a workaround for > this issue is in our backlog. > > — > Reply to this email directly, view it on GitHub > <#15056 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AA4Y6UH6JPY4RDDM2JS7MST2GJ5RZAVCNFSM6AAAAABT4B34EKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJTGAZDQOBSGM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >