Summary of Changes

Hello @luadebug, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to the xmake lua command by implementing the --from-stdin option. This new capability allows users to execute Lua scripts by providing their content directly through standard input, greatly improving the command's utility for dynamic scripting and integration into shell pipelines. The changes include the core logic for reading from stdin, proper argument handling, and robust error management, all backed by a new suite of tests to ensure reliable operation across different operating system shells.

Highlights

• New --from-stdin option: The xmake lua command now supports a --from-stdin option, allowing Lua scripts to be executed by reading their content from standard input.
• Standard Input Script Execution: This feature enables piping Lua code directly to xmake lua or redirecting content from a file, enhancing scripting flexibility.
• Comprehensive Test Coverage: New test cases have been added to tests/projects/test_stdin/xmake.lua to verify the --from-stdin functionality under various scenarios, including successful execution and error handling, for both standard shell and PowerShell.
• os.isexec Robustness Improvement: A minor adjustment in xmake/core/base/os.lua improves the os.isexec function by ensuring it correctly handles file executability checks, even if os._access is not available.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

If the implementation is too complex and makes it difficult to maintain, I will not consider supporting it.

If the implementation is too complex and makes it difficult to maintain, I will not consider supporting it.

1. I am just confused about stack trace. Should it really show stack trace?

2. Windows OS probably has sh tool if it has installed GIT/MinGW/Cygwin. I just tested on my Linux machine current implementation.

XMAKE_PROGRAM_DIR: /home/lin/xmake-luadebug/xmake
xmake binary: /usr/bin/xmake
Feature presence check: PASS
running: echo 'print("hello from pipe")' | /usr/bin/xmake lua --from-stdin
STDOUT 1:
hello from pipe
{ }

STDERR 1:

running: /usr/bin/xmake lua --from-stdin < /home/lin/xmake-luadebug/tests/projects/test_stdin/test.lua
STDOUT 2:
hello from file
{ }

STDERR 2:

running: echo 'raise("error_pipe")' | /usr/bin/xmake lua --from-stdin
STDOUT 3:
error: cannot import module: _2169751cbd80ae9a82df4e0ab747dfd5, error_pipe

STDERR 3:

running: /usr/bin/xmake lua --from-stdin < /home/lin/xmake-luadebug/tests/projects/test_stdin/error.lua
STDOUT 4:
error: cannot import module: _2169751cbd80ae9a82df4e0ab747dfd5, error_file

STDERR 4:

PowerShell 7.5.4
pwsh detected, running pwsh tests...
running pwsh: Write-Output "print(`"hello from pwsh pipe`")" | & '/usr/bin/xmake' lua --from-stdin
STDOUT 5:
hello from pwsh pipe
{ }

STDERR 5:

running pwsh: Get-Content '/home/lin/xmake-luadebug/tests/projects/test_stdin/test_pwsh.lua' | & '/usr/bin/xmake' lua --from-stdin
STDOUT 6:
hello from pwsh file
{ }

STDERR 6:

running pwsh: Write-Output "raise(`"error_pwsh_pipe`")" | & '/usr/bin/xmake' lua --from-stdin
STDOUT 7:
error: cannot import module: _2169751cbd80ae9a82df4e0ab747dfd5, error_pwsh_pipe

STDERR 7:

running pwsh: Get-Content '/home/lin/xmake-luadebug/tests/projects/test_stdin/error_pwsh.lua' | & '/usr/bin/xmake' lua --from-stdin
STDOUT 8:
error: cannot import module: _2169751cbd80ae9a82df4e0ab747dfd5, error_pwsh_file

STDERR 8:

I am not completely asure is it good or should behave different way for tests/projects/test_stdin. But I assume windows OS would require to wrap every variable related to path like xmath path or script path should be wrapped inside of path.unix(...)...

After changes in .c file it would print out

./build/xmake lua -c "print(os.programfile())"
/home/lin/xmake-luadebug/core/build/xmake

as expected to be from a start.

I dunno what's wrong now :?

I think I am still unable to resolve APE file issue on my Linux machine yet.

testing pwsh_single: pwsh -c "echo \"print('hello_pwsh')\" | env "/usr/bin/ape" l --stdin"
  -> failed
     out: 
     err: ape error: l: not found (maybe chmod +x or ./ needed)

error: [test_stdin]: Test failed! Expect: 

I don't understand what the APE problem is? Why is the xmake binary file located at /usr/bin/ape?

whereis ape ape: /usr/bin/ape APE loader aur package. I assume that is required in order to execute those sort of com files? Sorry mystery why os.programfile() returns /usr/bin/ape still remains unsolved.

./core/build/xmake l os.programfile
"/usr/bin/ape"

whereis cosmocc
cosmocc: /usr/bin/cosmocc /opt/cosmocc/bin/cosmocc

whereis ape
ape: /usr/bin/ape

I've tried using cosmocc to compile xmake on macOS/Linux, but I haven't been able to reproduce your problem.

It works for me. (dev branch)

ruki@dcc74edcdedc:/mnt/xmake$ file ./build/xmake
./build/xmake: DOS/MBR boot sector; partition 1 : ID=0x7f, active, start-CHS (0x0,0,1), end-CHS (0x3ff,255,63), startsector 0, 4294967295 sectors
ruki@dcc74edcdedc:/mnt/xmake$ xmake l core.base.binutils.format ./build/xmake
"ape"
ruki@dcc74edcdedc:/mnt/xmake$ ./build/xmake l os.programfile
"/mnt/xmake/build/xmake"

well, I got it. but it still does not work.

ruki@dcc74edcdedc:/mnt/xmake$ ./build/xmake l os.programfile
"/home/ruki/.ape-1.10"

Well I am busy for now maybe I will look into this in a future.

Well I am busy for now maybe I will look into this in a future.

I have fixed it.

/gemini review