busybox-w32/libbb/get_last_path_component.c, branch cron_changes

Merge branch 'busybox' into merge

2026-03-11T10:14:49+00:00

*: placate warnings where strchr/strstr returns constant pointer

2026-02-15T14:15:30+00:00

Newer glibc is now smarter and can propagate const-ness from those! function old new delta readtoken1 3111 3108 -3 Signed-off-by: Denys Vlasenko

win32: code shrink

2024-08-16T10:19:01+00:00

Add the FAST_FUNC qualifier to several Windows-specific functions. This has no effect in 64-bit builds but saves 336 bytes for 32-bit.

libbb: code shrink bb_get_last_path_component_strip()

2024-01-04T10:56:11+00:00

Use the new function last_char_is_dir_sep() to save 16 bytes in bb_get_last_path_component_strip().

realpath: improved support for Windows paths

2021-10-13T15:44:45+00:00

Upstream commit 94eb1c4dc (libbb: better coreutils compatibility for realpath) made some changes to xmalloc_realpath_coreutils(). This now needs to be updated to handle Windows paths. - Expose the macro is_unc_path() and part of the recent change to bb_get_last_path_component_nostrip() as a separate funtion, get_last_slash(); - Convert a couple of errors relating to network filesystems to ENOENT; - Adjust xmalloc_realpath_coreutils() to handle Windows directory separators, relative paths and UNC paths.

win32: fix bb_get_last_path_component_nostrip()

2021-10-13T13:21:18+00:00

Finding the last component of a path didn't properly handle a mixture of slashes and backslashes, paths relative to another drive or bare UNC paths. The following were incorrect: $ basename /dir\\file dir\file $ basename c:file c:file $ basename //HOST/share share With this patch the results are now: $ basename /dir\\file file $ basename c:file file $ basename //HOST/share //HOST/share

win32: improve handling of 'c:file' paths for executables

2020-03-18T11:27:05+00:00

bb_basename() didn't properly handle paths of the form 'c:file'. Attempting to run 'c:busybox' resulted in 'c:busybox: applet not found'. The shell had a similar problem: trying to run 'c:busybox' reported 'sh: c:busybox: not found'.

bb_basename: handle mixed slashes correctly

2017-08-24T07:37:25+00:00

A path like C:/WINDOWS\system32 was handled incorrectly: it found the forward slash, and then never bothered to look whether there was another (back-)slash later on. This fixes e.g. running BusyBox as C:/test\sh.exe Signed-off-by: Johannes Schindelin Signed-off-by: Ron Yorston

libbb: additional support for backslashes in paths

2015-11-13T08:51:45+00:00

Merge commit '56a3b82e9692a25ef9c9269e88feac0d579ce8e8' into merge

2012-03-22T15:21:20+00:00

Conflicts: coreutils/ls.c include/platform.h libbb/bb_basename.c