similar to: Ctrl-C at the Rterm prompt is remembered (unless pressing ENTER).

FYI, via a bug report of one of my packages, I discovered that the following cases will hang Rterm when using TAB completion: CASE #1: Adding an empty default function for tail() causes Rterm on Windows to hang if one press TAB at the prompt: % Rterm -vanilla > tail.default <- function(...) {} > [PRESS TAB] Error in specialOpLocs(text) : (list) object cannot be coerced to type

Hi, I'm running R v1.9.0 on WinXP Pro. I noticed that R.exe and Rterm.exe behave differently on Ctrl-C. Starting a Windows Command prompt (cmd.exe) you get from running Rterm.exe: C:\Program Files\R>rw1090\bin\Rterm.exe --vanilla --quiet > ^C > ^C > 1+1 [1] 2 > Sys.sleep(100) # Ctrl-C after a few seconds > ^C > ^C > 1+1 [1] 2 > q() C:\Program Files\R>

On Windows, 1. Open the Windows Command interpreter (cmd.exe). 2. Launch rgui.exe --vanilla. 2. In RGui, (disable Misc -> Buffered output) and run the following endless loop: > i <- 0; repeat { print(i <- i + 1); Sys.sleep(0.1) } [1] 1 [1] 2 [1] 3 ... 3a. Back at the Windows command line, press Ctrl-C (user interrupt). This will interrupt Rgui! 3b. Alternatively, start Rterm.exe

So do a number of other interactive programs when working in a terminal (e.g. python) since it looks like your terminal is configured for those two actions to send the SIGQUIT signal. Whether R should ignore that signal, under some circumstances at least, is another question. Best, luke On Fri, 10 Feb 2017, Henrik Bengtsson wrote: > When running R from the terminal on Linux (Ubuntu 16.04),

Is this a bug? do i have to complete a bug report? Is any other info needed? [root@nostromo ogg123]$ ./ogg123 -v -d oss /mnt/hdd/mp3/ripped/REM-Revival/track.08.ogg Playing from file /mnt/hdd/mp3/ripped/REM-Revival/track.08.ogg. Device: OSS audio driver output Author: Aaron Holtzman <aholtzma@ess.engr.uvic.ca> Comments: Outputs audio to the Open Sound System driver. Bitstream is 2

Hi Quinn, Am Do., 10. Sept. 2020 um 04:49 Uhr schrieb Quinn Comendant < quinn at strangecode.com>: > [...] > I don't see any significant errors in the boot log, but I would appreciate > if anyone has a moment to help me look for issues. Here's a copy of the > serial console boot log ? you can find the "Press Enter to continue" on > line 536:

Hi Thomas, On 10 Sep 2020 10:06:01, Thomas Bendler wrote: > If I'm not mistaken, problems after UTMP point to problems with X/ hardware > configuration. So I guess you might find more information when you also > have a look at the log files of systemd. I don't see any hardware issues. Here's the output from `journalctl -p 5 -xb`: https://write.as/2vjgz6pfmopg7fnf.txt The

I had similar issue on 7.6 - the LVM timeouts were too short and it was timing out as we had a lot of multipath devices. Once those were up , you could just continue. journalctl will show you what has happened. Best Regards, Strahil Nikolov ? ?????????, 10 ????????? 2020 ?., 18:57:02 ???????+3, Quinn Comendant <quinn at strangecode.com> ??????: Hi Thomas, On 10 Sep 2020

Update: I found a workaround to prevent entering emergency shell during boot for no reason. I've simply cleared the `OnFailure=` option for initrd-parse-etc.service (which was previously set to `OnFailure=emergency.target`). Now the server boots successfully without dropping into an emergency shell. This is a total hack, and I'm a little embarrassed that it's the only solution that

On 11 Sep 2020 17:23:00, Gordon Messmer wrote: > Run "systemctl daemon-reload && echo success" and verify that it > reports success, and not errors. > > Check the output of "systemctl status initrd-cleanup" too. Those have always reported success (even before I removed the OnFailure option): [~] sudo systemctl daemon-reload && echo success

On 12 Sep 2020 11:40:48, Gordon Messmer wrote: > In that case, I'd revert the change you made, unlock the root account > so that you can use the emergency shell, let the system boot to an > emergency shell, and collect the output of "systemctl status > initrd-parse-etc.service" and "journalctl -b 0". Ok, I was able to log in as root in the emergency shell.

On 9/12/20 1:04 PM, Quinn Comendant wrote: > I don't see any errors from `systemctl status initrd-parse-etc.service` or > `journalctl -b 0` (I've pasted the full output here:https://write.as/at21opjv3o9fin1t.txt) I see errors in the journalctl output.? Look into these: Sep 12 19:41:12 myhost systemd-vconsole-setup[84]: /usr/bin/setfont failed with error code 71. Sep 12 19:41:12

On 9/12/20 1:04 PM, Quinn Comendant wrote: > [root at myhost ~] systemctl status initrd-switch-root.service > ? initrd-switch-root.service - Switch Root > Loaded: loaded (/usr/lib/systemd/system/initrd-switch-root.service; static; vendor preset: disabled) > Active: failed (Result: signal) since Sat 2020-09-12 19:41:13 UTC; 17min ago > Process: 204

Thanks for these explanations - it all makes sense, that is, the default behavior for a process that does not capture SIGQUIT is to quit and perform a core dump (https://en.wikipedia.org/wiki/Unix_signal#SIGQUIT). Then the remaining question, as Luke says, is: should R handle this signal? For instance, in interactive mode, SIGQUIT could maybe bring up: Possible actions: 1: abort (with core

On 9/11/20 4:51 PM, Quinn Comendant wrote: > Does anyone know what initrd-parse-etc.service does? Or have suggestions how to troubleshoot that unit specifically? Run "systemctl daemon-reload && echo success" and verify that it reports success, and not errors. Check the output of "systemctl status initrd-cleanup" too.

In R v2.12.2 patched (2011-03-13 r54787) and also in R v2.13.0 devel (2011-03-15 r54806), .libPaths() may return the multiple paths referring to the same "normalized" path name. Here is an example from Rterm --vanilla using R v2.12.2 patched: > paths <- .libPaths(c("C:/", "C:\\")) > paths [1] "C:/" [2] "C:\\" [3]

Hello all, I've got an odd problem that doesn't seem to be mentioned anywhere. I have several identical CentOS 7 servers (GCE instances). I recently ran `yum update` and rebooted all of them. All the servers came back fine except one. I opened a connection to the serial console of the broken server, and was greeted with this prompt: ? Cannot open access to console, the root

On 9/11/20 5:29 PM, Quinn Comendant wrote: > Those have always reported success (even before I removed the OnFailure option): In that case, I'd revert the change you made, unlock the root account so that you can use the emergency shell, let the system boot to an emergency shell, and collect the output of "systemctl status initrd-parse-etc.service" and "journalctl -b

Gastman (cvs 05/21/03) coredumps when entering an empty (or any other) command in a command window. The backtrace follows... ... ---Type <return> to continue, or q <return> to quit--- Reading symbols from /usr/lib/gtk/themes/engines/libraleigh.so...done. Loaded symbols for /usr/lib/gtk/themes/engines/libraleigh.so Reading symbols from

In Section 'Package subdirectories' of 'Writing R Extensions', it says about the inst/ directory that: "The contents of the inst subdirectory will be copied recursively to the installation directory (except perhaps hidden files with names starting with ?.?)." Indeed, on Windows with R v2.12.0 patched (2010-11-01 r53513) and R v2.13.0 devel (2010-11-01 r53513), if you