VBS: Очистка экрана

Напрямую никак.

wisgest, работает. А мне так и не удалось ничего подобрать.

Значит, так и сделаем: VBScript: очистка экрана консоли (аналог CLS/Clear Screen) — Windows Script Host, HTA (VBScript, JScript) — Серый форум.

Замечания, предложения, дополнения?

Код черезчур избыточный,

                    .StdOut.ReadAll
                    .StdErr.ReadAll

по-любому обеспечит необходимую синхронизацию без .Status и WScript.Sleep().

Спасибо решение wisgest помогло.

Пока косвенных проблем не почувствовал. Посмотрим дальше.

Не обязательно. Описание свойства WScript.FullName из книги «Командные файлы и сценарии Windows Script Host»:

На мой взгляд, излишне по схожей причине.

Прошу прощения, имелось в виду, конечно же, свойство .FullName (исправил).
Просто я вначале хотел привести описание из той же таблицы для свойства .Path:

и в итоге сбился. А передумал потому, что в этом случае названия файлов сервера сценариев указаны безусловно, а в том присутствует оговорка в виде слова «обычно».

Насколько я понимаю речь идёт о чтении заголовка EXE-файла. Вполне возможно, не проверял. И насколько это просто сделать скриптом? Скорее всего, в случае wscript.exe/cscript.exe это будет работать однозначно, но всегда ли предопределено, будет приложение исполняться как консольное или нет?

В любом случае речь шла о более скриптовом решении с помощью «утиной типизации» (что на мой взгляд является самым правильным подходом),
а именно, вызовет ли ошибку

CreateObject("Scripting.FileSystemObject").OpenTextFile("CON")

Если скрипт выполняется не в консоли — это и есть критерий. Нет?

alexii, а что, возможно несоответствие: скрипт может выполнятся в консоли с помощью неконсольного хоста или наоборот? По-моему, задача одна и та же.

Хорошо, признаю, что предложенный приём позволяет определить именно в консоли или нет выполняется скрипт, а не спомощью какого хоста.
Но с прикладной точки зрения важнее узнать именно первое, поэтому приём не теряет свою значимость.

Для чего надо узнать, с помощью какого хоста (WScript.exe/CScript.exe, возможно, переименованного) выполняется скрипт? Для того лишь, чтобы узнать, как себя будет вести WScript.Echo()? Но, если заведомо требуется диалоговое окно, можно использовать
MsgBox() или WshShell.Popup(),
а если нужен вывод в StdOut, то
WScript.StdOut.WriteLine() или
CreateObject("Scripting.FileSystemObject").GetStandardStream(1).WriteLine()
— да, StdOut доступен и в WScript.exe, если его вывод перенаправляется/перехватывается (невозможно только перенаправление в CON):

wscript.exe script.js > log.txt
wscript.exe script.vbs | more
for /f %i in ('wscript.exe script.wsf') do echo %i

MsgBox WshShell.Exec("wscript.exe script.vbs").StdOut.ReadAll()

А вот от того, в консоли или нет выполняется скрипт, зависит управление из него консольных приложений с помощью WshShell.Exec():
если да, то значит так и было задумано и WshShell.Exec() не будет создавать новых окон;
если же нет, то WshShell.Exec() будет запускать каждое консольное приложение в новом окне (именно так себя ведет себя скрипт в примере alexii, выполняющийся с помощью CScript.exe без собственного консольного окна и с перехватом его вывода VbsEdit)
и, чтобы этого не происходило, можно, чтобы скрипт перезапускал сам себя под управлением консольного хоста в скрытом окне.

И тут встаёт обратная задача — получить путь к консольномо хосту сценариев: стоит ли предполагать, что это CScript.exe, находящийся в одном из каталогов, перечисленных в %Path% или возможно лучшее решение?
Я нашёл только запись в реестре:

C:\>reg query "HKLM\SOFTWARE\Microsoft\Windows Scripting Host\Locations"

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Scripting Host\Locations
    CScript     REG_EXPAND_SZ   %SystemRoot%\System32\cscript.exe
    WScript     REG_EXPAND_SZ   %SystemRoot%\System32\wscript.exe

— Испольуется ли этот раздел для чего нибудь или это только атавизм, присутствует ли он в 64-разрядных системах?