treewide: fix path to shell related tests in doc

cpu/esp32/doc.txt

@@ -576,11 +576,11 @@ command, for example:
 - RIOT Docker build image installation
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
-    make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
+    make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 - Local toolchain installation
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  $ make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
+  $ make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The `BOARD` variable in the example specifies the generic ESP32 board that uses
@@ -2051,12 +2051,12 @@ installed.
 To use QEMU for ESP32, an application has to be built with `esp_qemu` module
 enabled, for example with local toolchain installation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 or with RIOT Docker build image
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
-  USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+  USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Instead of flashing the image to the target hardware, a binary image named
@@ -2070,7 +2070,7 @@ QEMU for ESP32 can then be started with command:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ qemu-system-xtensa \
     -s -machine esp32 \
-    -drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
+    -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
     -serial tcp::5555,server,nowait
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2099,12 +2099,12 @@ start_test           starts a test
 
 To debug the application in QEMU for ESP32, another terminal is required:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
+$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
 
 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
 Copyright (C) 2015 Free Software Foundation, Inc.
 ...
-Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
+Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
 (gdb) target remote :1234
 
 Remote debugging using :1234
@@ -2117,10 +2117,10 @@ QEMU for ESP32 can also be used in RIOT Docker build image. For that purpose
 QEMU has to be started in the Docker container.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ sudo docker run --rm -i -t -u $UID -v $(pwd):/data/riotbuild riot/riotbuild
-riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 riotbuild@container-id:~$ qemu-system-xtensa \
     -s -machine esp32 \
-    -drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
+    -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
     -serial tcp::5555,server,nowait
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2144,12 +2144,12 @@ test_shell.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ sudo docker docker exec -it <container-id> bash
-riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
+riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
 
 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
 Copyright (C) 2015 Free Software Foundation, Inc.
 ...
-Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
+Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
 (gdb) target remote :1234
 
 Remote debugging using :1234

cpu/esp8266/doc.txt

@@ -59,7 +59,7 @@ To build a RIOT application, simply use the `make` command and specify an
 existing ESP8266 board, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make flash BOARD=esp8266-esp-12x -C tests/shell ...
+make flash BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For more information about the `make` command variables and specific compile
@@ -283,7 +283,7 @@ directory, a RIOT application can be compiled inside RIOT Docker using the
 make command as usual, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make BOARD=esp8266-esp-12x -C tests/shell ...
+make BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This will generate a RIOT binary in ELF format.
 
@@ -295,7 +295,7 @@ of the compilations is also accessible on the host system. On the host system,
 the `flash-only` target can then be used to flash the binary.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make flash-only BOARD=esp8266-esp-12x -C tests/shell
+make flash-only BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 @note Both steps can also be performed with a single command on the host
@@ -1126,7 +1126,7 @@ For debugging purposes, the application should be compiled with debugging
 information. This can either be done by using the `esp_gdb` module, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/shell
+USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [Back to table of contents](#esp8266_toc)
@@ -1162,7 +1162,7 @@ term1> $QEMU/bin/qemu-system-xtensa -M esp8266 -nographic -serial stdio -monitor
 
 where `/path/to/build/dir` is the path to the application build directory
 `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
-`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`. After that you can
+`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`. After that you can
 start `GDB` in second terminal window using command:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1203,7 +1203,7 @@ To start debugging, the application has to be compiled using
 module `esp_gdbstub`, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/shell
+USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Once, the application is flashed to ESP82666, debugging can be started as
@@ -1223,7 +1223,7 @@ term2> xtensa-esp8266-elf-gdb /path/to/the/build/dir/image.elf
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 where `/path/to/build/dir` is the path to the application build directory
 `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
-`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`.
+`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`.
 
 3. Connect from `GDB` to the ESP8266 module with command:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1250,7 +1250,7 @@ the application stepwise or just continue the execution using the `continue`
 command. Please note the limitations below. Once you have started the execution
 in `GDB`, you can use `Ctrl-C` in `GDB` or the console window to break it anytime.
 
-If your application uses console inputs (stdio), such as the `tests/shell`
+If your application uses console inputs (stdio), such as the `tests/sys/shell/`
 application, you can type characters in the console window that gdbstub will
 forward to the application. However, the echo of these inputs occur in `GDB`.
 

dist/pythonlibs/testrunner/spawn.py

@@ -41,7 +41,7 @@ TEST_INTERACTIVE_DELAY = int(os.environ.get('TEST_INTERACTIVE_DELAY') or 1)
 TESTRUNNER_RESET_AFTER_TERM = int(os.environ.get('TESTRUNNER_RESET_AFTER_TERM')
                                   or 0)
 
-# When running e.g. tests/shell_ble we don't want to reset the board, because
+# When running e.g. tests/sys/shell/_ble we don't want to reset the board, because
 # then ble-serial would terminate and the created virtual serial port would get
 # lost. By default the board is reset before the test starts.
 TESTRUNNER_RESET_BOARD_ON_STARTUP = \

dist/tools/compile_test/compile_like_murdock.py

@@ -52,7 +52,7 @@ DEFAULT_APPS = [
     "examples/hello-world",
     "tests/pkg/tinyusb_cdc_msc",
     "tests/mtd_mapper",
-    "tests/shell",
+    "tests/sys/shell/",
     "tests/saul"
 ]
 

dist/tools/compile_test/tests/test.sh

@@ -38,7 +38,7 @@ function call_with_defaults {
 function call_with_specific_board_app {
     ${COMPILE_TEST_DIR}/compile_like_murdock.py \
     --boards native \
-    --apps tests/shell \
+    --apps tests/sys/shell/ \
     --dry-run
 }
 

dist/tools/vagrant/freebsd/README.md

@@ -31,8 +31,8 @@ See the general vagrant [README.md](../README.md) for more commands.
 Once logged in to the VM you can run compile and run tests e.g.
 
 ```sh
-make -C tests/shell all -j
-make -C tests/shell test
+make -C tests/sys/shell/ all -j
+make -C tests/sys/shell/ test
 ```
 
 Even applications requiring network interface access should be able to work:

sys/stdio_nimble/README.md

@@ -41,7 +41,7 @@ Otherwise the device will appear as "*RIOT OS device*".
 
 ## Instructions to connect to the bluetooth shell via ble-serial
 
-- Configure and compile shell app for nrf52840dongle target in `tests/shell`.\
+- Configure and compile shell app for nrf52840dongle target in `tests/sys/shell`.\
 
 Add following to Makefile:
 ```
@@ -50,11 +50,11 @@ USEMODULE += nimble_autoadv
 USEMODULE += stdio_nimble
 ```
 
-**NOTE:** You can also have a look at `tests/shell_ble`.
+**NOTE:** You can also have a look at `tests/sys/shell_ble`.
 
 - Flash
 
-`$ make -C tests/shell -j clean all flash`
+`$ make -C tests/sys/shell -j clean all flash`
 
 - Install the ble-serial tool
 

tests/sys/shell_ble/Makefile

@@ -8,7 +8,7 @@ USEMODULE += ps
 
 USEMODULE += stdio_nimble stdio_nimble_debug
 USEMODULE += nimble_autoadv
-CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/shell_ble"'
+CFLAGS += -DCONFIG_NIMBLE_AUTOADV_DEVICE_NAME='"tests/sys/shell/_ble"'
 
 TESTRUNNER_SHELL_SKIP_REBOOT = 1
 TESTRUNNER_RESET_BOARD_ON_STARTUP = 0