Fix SystemNative_IsATty P/Invoke missing on iOS/tvOS/MacCatalyst

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306

[Copilot]

System.Diagnostics.Process has a P/Invoke to SystemNative_IsATty, but that symbol is not exported by libSystem.Native on iOS, tvOS, and Mac Catalyst, causing a runtime failure on those platforms.

Description

Guard SystemNative_IsATty in pal_console.c to unconditionally return 0 on TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST — there is no terminal on these platforms.

int32_tSystemNative_IsATty(intptr_tfd)
{
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS)
// there is no terminal on these platforms
(void)fd;
return0;
#elsereturnisatty(ToFileDescriptor(fd));
#endif
}

This follows the same #if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) guard pattern used elsewhere in the native libs (e.g., pal_icushim_static.c, pal_x509.c).

fixes#126299

[adamsitnik]

LGTM!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a runtime P/Invoke failure on iOS/tvOS/MacCatalyst by ensuring SystemNative_IsATty is always present in libSystem.Native, while returning a consistent “not a TTY” result on platforms where TTY semantics don’t apply.

Changes:

• Add an Apple mobile/Catalyst preprocessor guard to SystemNative_IsATty.
• On TARGET_IOS, TARGET_TVOS, and TARGET_MACCATALYST, return 0 without calling isatty.

[adamsitnik]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

[MichalStrehovsky]

@rolfbjarne is this the correct fix? or is pal_console.c not compiled for iOS family because there is simply no terminal there?

It pulls in pal_log.m instead (the .c is only included on macOS):

runtime/src/native/libs/System.Native/CMakeLists.txt

Lines 68 to 94 in 7c91160

	if (CLR_CMAKE_TARGET_APPLE)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC
	pal_autoreleasepool.m
	pal_environment.m
	pal_searchpath.m
	pal_datetime.m)
	if (CLR_CMAKE_TARGET_MACCATALYST OR CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_log.m)
	if (CLR_CMAKE_TARGET_MACCATALYST)
	list (APPEND NATIVE_SOURCES_OBJC_NO_ARC pal_iossupportversion.m)
	else()
	list (APPEND NATIVE_SOURCES pal_iossupportversion.c)
	endif ()
	elseif (CLR_CMAKE_TARGET_OSX)
	list (APPEND NATIVE_SOURCES
	pal_console.c
	pal_log.c
	pal_iossupportversion.c)
	else()
	message(FATAL_ERROR"Unsupported Apple platform")
	endif ()
	set_source_files_properties(${NATIVE_SOURCES_OBJC_NO_ARC} PROPERTIES COMPILE_FLAGS"-fno-objc-arc ${CLR_CMAKE_COMMON_OBJC_FLAGS}")
	list (APPEND NATIVE_SOURCES ${NATIVE_SOURCES_OBJC_NO_ARC})
	else()

The ConsolePal.iOS.cs is pretty barebones, I would look why the p/invoke is even included instead of trying to stub out.

[akoeplinger]

verify-entrypoints.sh was supposed to catch this, but we haven't turned it on for mobile. would be nice to fix that

[adamsitnik]

I've also opened #126305 to ensure I don't break any mobile platforms again (I already added tests for Android to avoid that, but missed the catalyst vs ios difference)

[MichalStrehovsky]

Oh the reference is from Process? Out of curiosity I had a look and...

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Lines 363 to 392 in 36e6179

	if(PlatformDoesNotSupportProcessStartAndKill)
	{
	thrownewPlatformNotSupportedException();
	}
	EnsureInitialized();
	string?filename;
	string[]argv;
	IDictionary<string,string?>env=startInfo.Environment;
	string?cwd=!string.IsNullOrWhiteSpace(startInfo.WorkingDirectory)?startInfo.WorkingDirectory:null;
	boolsetCredentials=!string.IsNullOrEmpty(startInfo.UserName);
	uintuserId=0;
	uintgroupId=0;
	uint[]?groups=null;
	if(setCredentials)
	{
	(userId,groupId,groups)=GetUserAndGroupIds(startInfo);
	}
	// .NET applications don't echo characters unless there is a Console.Read operation.
	// Unix applications expect the terminal to be in an echoing state by default.
	// To support processes that interact with the terminal (e.g. 'vi'), we need to configure the
	// terminal to echo. We keep this configuration as long as there are children possibly using the terminal.
	// Handle can be null only for UseShellExecute or platforms that don't support Console.Open* methods like Android.
	boolusesTerminal=(stdinHandleis not null&&Interop.Sys.IsATty(stdinHandle))
	||(stdoutHandleis not null&&Interop.Sys.IsATty(stdoutHandle))
	||(stderrHandleis not null&&Interop.Sys.IsATty(stderrHandle));

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

System.Diagnostic.Process already multitargets, and it already did multitarget when people added the if check. Weird. This feels like something that should be a partial class.

[adamsitnik]

The PlatformDoesNotSupportProcessStartAndKill at the beginning is exactly iDevices. So this should all be unreachable.

But Process is supported on mac catalyst and not supported on iOS and tvOS:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs

Line 993 in 508f440

=>(OperatingSystem.IsIOS()&&!OperatingSystem.IsMacCatalyst())||OperatingSystem.IsTvOS();

FWIW we could support it on iOS with my most recent changes (I think: #126097 (comment))

[adamsitnik]

This feels like something that should be a partial class.

Let's say there is a place for improvement and I am trying really hard to make it happen right now ;P

[rolfbjarne]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

[rolfbjarne]

There's a terminal on Mac Catalyst (but none on iOS or tvOS).

[adamsitnik]

I'm not sure I understand how this is going to fix anything, because only changing SystemNative_IsATty doesn't do anything because SystemNative_IsATty isn't built for these platforms in the first place.

You are right, it's not going to fix the problem and that is why I've asked you to review this PR (#126302 (comment)) as I have no clue about mobile targets

[adamsitnik]

Let's get the tests at least failing first in #126306