On two machines that are identical in kernel version and hardware, I start a tmux session, and type env.
On one machine, I see EVENT_NOEPOLL=1. On the other one, I do not see this line. This behavior persists across reboots.
What might cause tmux to set the variable in one case but not the other?
Edit: I found the source code, but I still do not understand why it is set only sometimes.
struct event_base *
osdep_event_init(void)
{
/* On Linux, epoll doesn't work on /dev/null (yes, really). */
setenv("EVENT_NOEPOLL", "1", 1);
return (event_init());
}
Related
I use zsh 5.8 (oh-my-zsh + my custom configs) with iTerm2.
I want every zsh instance to store the command to the history every time I type it and share the history with the others.
It basically works as I want, but the problem is, if I (manually) quit iTerm2 with multiple tabs open (e.g. so that I can recover those tabs after reboot), the zsh_history file loses most of its content and contains only the first N commands.
My guess is the zsh instances kind of compete with each other in the last moment.
HISTSIZE and SAVEHIST are set largely enough (10000000).
setopt prints:
alwaystoend
autocd
autopushd
noclobber
completeinword
extendedhistory
noflowcontrol
histexpiredupsfirst
histfcntllock
histignoredups
histignorespace
histverify
incappendhistory
interactive
interactivecomments
login
longlistjobs
monitor
promptsubst
pushdignoredups
pushdminus
sharehistory
shinstdin
zle
Is there any way I can prevent this from happening?
EDIT: After seeing the comment, I disabled inc_append_history, but it's happening again.
EDIT2: Disabled appendhistory as well, but still the same.
EDIT3: After manually unsetting histsavebycopy (i.e., nohistsavebycopy), looking good so far.
EDIT4: Since the last change (EDIT3), I've experienced zsh: corrupt history file once.
EDIT5: Lost some history even without the corrupt history file error.
I have this issue with chef, namely kitchen.local.yml.
It overrides kitchen.yml, that works.
But when I remove the overridden attribute, it behaves like it is not removed. It looks like it is somehow cached.
I can only change the value. This causes issues because i can't get the default attribute coming from the attributes/*.rb.
This is .kitchen.local.yml:
suites:
- name: default
run_list: [ "recipe[bbcpd-bpds-api]" ]
attributes: {
"bbcpd-bpds-api": {
"redis": {
#"host": "${REDIS_PORT_6379_TCP_ADDR:-10.0.2.2FOOO}",
### This above seems to stick even though commented out.
### Changing it FOOO to BAAR works.
### But removing keeps the BAAR appearing
### unless I `kitchen destroy` and recreate again.
}
}
I didn't find the FOOO value on host machine except for the commented out line and logs.
On the guest machine (VM), I found it in /tmp:
kitchen/dna.json:{"bbcpd-bpds-api":{"update_mode":true,"redis":{"dbIndex":"12","host":"${REDIS_PORT_6379_TCP_ADDR:-10.0.2.2FOOO}"},"storage":{"ccr":{"url":"https://ccr-dev-citc.bbcollab.com/v1","client":"BPDS-Client-Id","secret":"ABCDEFGHABCDEFGHABCDEFGHABCDEFGHABCDEFGHunzoneunzoneunzoneunzoneunzoneunzoneunzoneunzone","tokenexpiry":"60","site":"Dev","container":"DevBPDSContainer"}},"libreoffice":{"binary":"/opt/libreoffice5.4/program/soffice"}},"run_list":["recipe[bbcpd-bpds-api]"]}
kitchen/nodes/default-centos-72.json: "host": "${REDIS_PORT_6379_TCP_ADDR:-10.0.2.2FOOO}",
I am not quite sure what is the role of these, but I suspected these are somehow involved in keeping the state.
I have tried to delete /tmp but then, kitchen converge stopped working. It needed kitchen create to fix. But the ...FOOO value appeared there again.
Running kitchen destroy && kitchen create makes the value go away, but since there is no caching for the VM base image, it takes around 15 minutes, so I would like to avoid it.
Questions:
Where are these values being cached so that they stick even after removed from .kitchen.local.yml?
How can I disable/clear that caching?
This is just how it works, sorry. You have to destroy and recreate the instance to see changes in attribute settings.
in prokb,its mentioned
In 10.0B02 and above, the client session startup parameter -noincrwarn was reintroduced
to allow the selective suppression of the above four warning messages ONLY. Since the
execution of the 4GL statement: SESSION:SUPPRESS-WARNINGS = YES. suppresses ALL warning
messages during the session.
Where and how could i set i this startup parameter -noincrwarn to suppress this warning
message?
"SESSION:SUPPRESS-WARNINGS = YES." doesn't do much of anything useful. Or at least it didn't the last time I tested it.
The -mmax warning is harmless. It is a "soft" limit that is dynamically allocated and expanded as needed. You can ignore it. Or if the .lg file entries really bother you, you can simply increase it to a reasonable value. I routinely set it to 8192 for character sessions, 32768 for Windows. The default, as JensD says, is ludicrously low.
Startup parameters, such as -noincwarn, can set in a number of ways:
1) Via the command line. If your application starts via a script it will eventually invoke progress via "pro", "mpro", progress, prowin32, proapsv or some other executable (you can potentially link your own objects and create custom executables...) The command line that invokes Progress will have a number of parameters. You could add it there. Windows example:
#echo off
set DLC=\Progress\OpenEdge
%DLC%\bin\prowin32 -db mydb -p start.p -noincwarn
(On windows it is also common for the shortcut properties to have the command line listed.)
2) In a "pf" file. "PF" files are parameter files. They contain a list of parameters in a text file. This makes it easy to share and manage parameters between many scripts. To use a parameter file you need at least one -pf filename.pf parameter. Unix example:
#!/bin/sh
DLC=/usr/dlc
export DLC
${DLC}/bin/_progres -db mydb -pf mypf.pf
Where "mypf.pf" might contain:
# mypf.pf
-p start.p
-noincwarn
There is a global .pf file in the Progress install directory called startup.pf. You could also add it to that.
3) In an "ini file". Sort of like the pf file but more complicated. Indicated by the -ininame startup parameter. Can also be influenced by registry keys.
Why not removing or trying another value for -mmax? If you're moving from an old version of Progress it might be that -mmax is set very low.
The Maximum Memory (-mmax) client session parameter specifies the maximum amount of memory allocated for r-code segments, in kilobytes.
Source: http://knowledgebase.progress.com/articles/Article/P11351?popup=true
Large memory consumption might depend on complicated business logic (things like very large and or deeply nested procedures) so you might consider looking into that.
However a much easier fix would be to increase the value. Default is 3096, meaning each client "only" gets 3 Mb for this. Not a very large amount with today's standards.
If you really only want to suppress the message. Set -noincrwarn in your client side startup script (or corresponding .pf-file/startup.pf).
Hosting a WPF element (windows Presentation Foundation) in an OpenEdge application can cause application to crash if any message cover the window. It is also the case of this message.
In order to suppress any messages including message 5409 ()
According to article "HOW TO SUPPRESS WARNING MESSAGES (5407),(5408),(5409),(5410) FROM DISPLAYING ON CLIENT SCREENS."
I used with expected results SESSION:SUPPRESS-WARNINGS = YES. As the first line in the starting procedure of the aplication.
Using -noincrwarn as the session startup parameter had no effect in Open Edge 11.4
Supress openedge messages:
http://knowledgebase.progress.com/articles/Article/P79795?popup=true
.NET related error for OpenEdge-WPF hibrid application "Invisible or disabled control cannot be activated"
https://social.msdn.microsoft.com/Forums/windows/en-US/e8cf6431-2a59-4335-8b36-fc8f35083823/invisible-or-disabled-control-cannot-be-activated?forum=winforms
My .zshrc file contains the line
bindkey -v
I'm attempting to bind ^q or \M-q to push-line, e.g.
bindkey "^q" push-line
but for some reason it isn't working.
Running `bind key -v' confirms
"^Q" push-line
But it doesn't actually do anything. Other control- mappings, such as ^r, work fine.
I can successfully map "push-line" to "\eq", but I don't like this behavior. First of all, I never use esc- type bindings, and secondly doing so binds it to control, meta, and escape, which is overkill. (Incidentally, shouldn't it only bind all of them like that with `bindkey -m'? I never set that in my .zshrc?)
So, anybody have any idea what's going on here?
These shortcuts are used by Software flow control (wikipedia)
Ctrl+S and Ctrl+Q are used to stop and resume the output of a program.
To try it:
Run while (true) ; do echo $RANDOM ; sleep 1 ; done
Press Ctrl+S, the output stop.
Press Ctrl+Q, the output resume.
(I'm not sure the program is stopped like with Ctrl+Z, i think it is stuck by lack of outputting. Ctrl+C to kill the program.)
These shortcuts take over your shortcuts, but if you disable this flow control feature, it could work.
You can learn how to disable it in How to unfreeze after accidentally pressing Ctrl-S in a terminal? - Unix and Linux.
Try it and tell us.
I've been playing around with some ANSI stuff (like colors etc.) in java and php (from scratch) and I'm trying to find a way to basically wait for a key press. I'd like to have something like the following pseudo code at the end of my main event loop:
If (KeyPressed)
Begin
var event = new KeyboardEvent();
event.Key = ReadKey();
this.BubbleEvent(event);
End
But everything I've been trying over the last couple days fails because the key presses only become available on STDIN after the user has pressed enter.
It doesn't matter much what language you answer in, but java, php, plain old c or c# would be nicest, and I cannot use any really spiffy library stuff because I need to port it to all four of those languages... I need this to work over a telnet or ssh connection, but my research so far suggests it is impossible unless you're working on the local machine.
Please prove me wrong.
The curses function cbreak(3) will disable line-buffering and erase/kill handling. You can do this yourself with stty(1) if you really want.
When your program dies and leaves the terminal in cbreak mode, you can usually use either stty sane or reset to bring the terminal back to a reasonable state.
From within Perl, you can use either the Term::ReadKey or the Curses module to manipulate the terminal. See the Term::ReadKey(3pm) or Curses(3pm) manpage for details.
From within C, you can use either ioctl(2) calls on the terminal device to turn on cbreak mode, or you can use curses. See the ncurses(3) manpage for details.
I know, this is an old thread, but I could not find a suitable answer anywhere else. So with some help from the senior programmers of my company I came up with this:
private void waitKeypress() throws IOException
{
System.in.read();
while ( System.in.available() > 0 )
{
System.in.read();
}
}
The part reading as much input as is available solved my problem that when used multiple times, "System.in.read()" alone does not always wait.
For me this does the trick, I use it like this:
doSomething();
waitKeypress();
doNextThing();
Hope it helps.
Kind regards,
Ralph