Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Can anyone help in making me understand, what's the real difference between chroot command and chroot() system call.
A system call is a means for a program to interact with the kernel.
A unix tool command is either a small stand alone program (in this case) or else a shell built in (in some other cases). This allows a user or a script to perform operations without having to provide low level program code for doing so.
Where a command and a system call have the same name, typically the command provides a way to accomplish the functionality of the system call, or something similar.
System calls are documented in section 2 of the manual, while commands may be elsewhere such as page 8. So if you type
man 2 chroot you will get the documentation for the system call
and if you type
man 8 chroot (or in many cases simply fail to specify a page) you will get the documentation for the command.
if you type
which chroot you will find the location of the executable which implements the command, assuming it is in your search path as it usually would be.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
anyone explain me about why and where we use log.info and log.error and logUtils.error and ExceptionLog error. we can also use system.out.println for printing but why we use logs for printing and why we have these many of logs?
Generally we don't use println for logging because there are libraries that are much better at that and configurable. println means that the message is going to be printed to standard output every time, but logging libraries let us define configuration file, outside of code, that defines what log level we want to log to which output for example send it over the network or save it into the file, we can choose the layout of on log line and customize it to get information that is meaningful to us and this is just part of configuration capabilities. Basically we want as much freedom of logging configuration without changing the code as possible. That allows us to define different behaviors across different environments, different configuration for each package etc and helps us to stay consistent throughout whole application.
Practical example is my production application that logs to central log server and send logs over network, besides that it just logs to console, but in my development environment it logs to a file directly. So I can build application in my development environment and deploy it in production without thinking about logging because it depends on the configuration file.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I was reading operating system concepts by Silberschatz and i came across
"Some operating systems include the command interpreter in the kernel"
statement.
I cannot understand how such an arrangement will be implemented. also if you cn give some examples of os which provide such arrangement.
Thank you for taking time to help.
Some operating systems do this, like vxWorks. It's just taking the shell itself, and packing it into the kernel. If you can do something in user space (ie: shell as a user space application), you can do it (with some difficulty) in the kernel. The usual caveats apply, such as not being able to link user space libraries into kernel code, etc.
It's easy, on Linux for example, to write directly to a PTY from a kernel module. You can just as easily get the stdin for a process by hijacking system calls, among other methods. Now you have your I/O mechanisms, and just need a parser to handle all the internal logic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have heard good things about Chef, was curious about all of the benefits before I devote time to learning a new tool. Not looking to turn this into opinion thread, looking for a list of additional features it has over makefile/shell script.
Chef, and Ansible/Puppet/Salt too (collectively called CAPS), are all based on the structure of "describe the desired state of the system and the tool will make it happen".
A script or Makefile is generally a procedural system, run this, then run that, etc. That means you need to keep a mental model of system from each step to the next, and if that ever deviates from the real system (ex, a directory you are trying to set the owner of doesn't exist) your script usually breaks.
With some stuff this is easy, like yum/apt-get install as they are internally idempotent, you can run them every time and if the package is already installed, it just does nothing.
CAPS systems take that principle (idempotence) and apply it to all management tasks. This has for the most part resulted in less brittle configuration management as you only need to tell the tool what the end result should look like and it will take care of figuring out the delta from the current state.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
When creating a netcat-like program how do I get that file onto a server? It seemed like the reason for creating a netcat-like program was to be able to use it to run commands, get files and connect to ports.
So it seems like it's necessary to have it on the server in order to put it on the server?
I'm probably just really confused.
You'd use another program to load it initially. For example, you might ssh in.
It is also possible that you'd have physical access to the server and could install the first file transfer program manually, or as part of the intial OS install.
Not all interactions have to be done remotely. Otherwise, your intuition would be right -- we'd have a chicken and egg problem.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
To aid in the ability to multitask, I added a datastep that would play the first three notes of hot cross buns after my program would finish, so I could just minimize SAS and do something else while it runs.
The thing is, I've had a few complaints from colleagues that they would forget that their volume was up all the way, and would receive a not-so-pleasant surprise when their program would complete.
Is there a way to pull in system info, more specifically, the computer volume level, so I can set a threshold in which the music will play or not?
It can be done but is not easy or elegant - especially if you want to distribute the code. If you wanted to do it programmatically you would have to make a call to the relevant windows API DLL from SAS:
http://support.sas.com/documentation/cdl/en/hostwin/63285/HTML/default/viewer.htm#overdll.htm
As the article says it's not easy (and not guaranteed to work). The DLL you would be interested in is the one below:
Changing master volume level
A kludge solution would be to find a 3rd party program that takes command line calls to change the volume:
http://www.google.com/search?hl=en&client=firefox-a&hs=Tql&rls=org.mozilla%3Aen-US%3Aofficial&q=windows+change+volume+command+line&aq=f&aqi=&aql=&oq=
You could then call that using the 'x' comamnd in SAS. The issue here would be that you would need to install the 3rd party app on every machine that used your volume code.
Cheers
Rob
I think the short answer is the the SAS SOUND function has two parameters: pitch and duration. Since volume is not a parameter, you can't control the volume without making a call to the OS.