Tag Info

Hot answers tagged

22

look at the time man page on your system, some implementations have format options to include I/O, CPU and Memory stats (-f). For instance, GNU time, with -v will show all available info (here on Linux): /usr/bin/time -v ls Command being timed: "ls" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall ...


13

There are DST-free timezone definitions provided which just define the GMT-offset, called Etc/GMT±X: $ date Mon Apr 7 11:08:56 CEST 2014 $ TZ=Etc/GMT-1 date Mon Apr 7 10:09:16 GMT-1 2014 $ Just link/copy the one you need to /etc/localtime and you should be fine and DST-free: $ ln -s /usr/share/zoneinfo/Etc/GMT-1 /etc/localtime Edit: For non-integer ...


12

If I understand what you're asking for I this will do. I'm using the commands ls ~ and tee as stand-ins for ./foo and bar, but the general form of what you want is this: $ ( time ./foo ) |& bar NOTE: The output of time is already being attached at the end of any output from ./foo, it's just being done so on STDERR. To redirect it through the pipe you ...


10

By using strace, I saw that the line number=$(expr $number + 1) causes a fork, path search, and exec of expr. (I'm using bash 4.2.45 on Ubuntu). That filesystem, disk, and process overhead led to bash only getting around 28% of the CPU. When I changed that line to use only shell builtin operations ((number = number + 1)) bash used around 98% of the ...


7

No. Process/context switches aren't free. How much other processes running will slow yours down is very system-dependent, but it consists of things like: Every time a processor switches to a different address space (including process), then the MMU cache must be flushed. And probably the processor L1 caches. And maybe the L2 and L3 caches. This will slow ...


5

time sends its output to stderr instead of stdout by default. You just need to redirect that where you want it. You say "On the other hand, if I wanted to time foo, and redirect the output of time I could write, time (./foo) | bar." but this is actually incorrect. In this case, the output of time would still be displayed on your console, only stdout would ...


5

Correct, usually shell built-ins have help pages instead since their usage isn't usually that involved. If the built-in commands were all that complicated, there would have likely been an effort to simplify shell logic by pushing that functionality into its own executable, at which point it would get a man page. You can get information on time by using ...


5

On OS/X or FreeBSD, it's the -U option. Linux now also stores the birth/creation time on most of its native file systems, but there's no API to retrieve it yet. On ext4 filesystems, you can use debugfs to get it though: $ sudo debugfs /dev/some/fs stat /some/file [...] crtime: 0x53208d7a:9045625c -- Wed Mar 12 16:38:18 2014 [...] (where /some/file is the ...


5

No, you should not be prompted for a password again. The script will be running as root due to the gksudo. In my experience, sudo never asks for password if you are already root (although I couldn't find this explicitly documented).


5

The usual solution to this problem is to put your time command in a group: $ { time wc test >wc.out; } 2>time.out


5

The system clock and the hardware clock are not the same. The command hwclock -r should show you the time the hardware clock is set to. If it is incorrect, use the command hwclock -w to update it when the time is correct. If you dual boot with windows, you will want to use local time. Otherwise, you may want to set the harward clock to UTC with the ...


5

In bash: $ type -a time time is a shell keyword time is /usr/bin/time You called time, cause bash invoked time built in keyword instead of external /usr/bin/time command. time built in keyword does not have option -v. bash interpreted that you calling built in time on command -v, causing this error. Try: /usr/bin/time -v ls or: command time -v ls


4

On most systems, you can use the ulimit command when you start the program to limit the amount of CPU time it can use. Under the hood, this calls setrlimit with the argument RLIMIT_CPU. After the program has used that much time, the program is killed. (ulimit -t 3600; myprogram) You can refine further by setting a soft limit after which the program ...


4

Call time myprogram. This reports wall clock time, user time and system time. User time is the time spent by the process in computations. If the program is multithreaded and the machine has multiple processors, the time spent on all processors is summed (so for a sufficiently parallel program, the user time can be more than the wall clock time). The system ...


4

In ksh, bash and zsh, time is a keyword, not a builtin. Redirections on the same line apply only to the command being timed, not to the output of time itself. $ time ls -d / /nofile >/dev/null 2>/dev/null real 0m0.003s user 0m0.000s sys 0m0.000s To redirect the output from time itself in these shells, you need to use an additional level ...


4

On Linux, the info is available in fields 14 to 17 of /proc/$pid/stat (see proc(5) for details): Fields are: 14: user time (in number of clock ticks) 15: sys time 16: user time of waited for children 17: sys time of waited for children (all the threads of a given process have the same values there) They are not directly reported by ps. ps reports 14 + ...


4

You can run a command (including a shell and all of its children) with an arbitrary faster clock frequency by using the warp command from the ast-open package. It uses LD_PRELOAD, so won't work with setuid or setgid or (now relatively rare) statically-linked programs. From the warp man page: warp [ options ] date [ command [ arg ... ] ] warp ...


3

It's because you're echoing all the numbers out to the screen via the puts. These then have to be sent over the SSH connection which extends the amount of time the scripts takes to run. The output is also buffered locally but the effects aren't as noticeable. You can confirm this by dumping all the output to a file instead. Examples local on laptop to ...


3

Printing to a console (especially a remote console) is a fairly expensive operation if done in a tight loop that's executed frequently. Most Ruby I/O is blocking, so it will drastically slow down the execution of the program. You should get a much more reasonable result if you send the output to a file (or /dev/null, if you don't care about it) instead: ...


3

From usr/share/doc/at/timespec, it doesn't look like it. But you can always use date to convert your timestamp, eg: at "$(date --date=@1393419435 +'%D %T')" date takes a timestamp in seconds, so don't forget to trim fractions of seconds if needed.


3

I tried the following in my .bashrc: echo -ne "$PS1" while IFS= read -er line;do eval "time $line" echo -ne "$PS1" done This roughly does what you want with several caveats: Your prompt is practically ruined (the shell usually interprets sequences like \W and so on in your prompt before echoing it). You lose command line editing capabilities ...


3

Since $GPSDATE is being reported as Sun Aug 8 06:08:11 PKT 2010 the date -s command is doing exactly what you are telling it to do. Why is it reporting a wrong year (or nothing at all)? I have no idea. Since you are already using ntpd why are you not content to let NTP do its thing? Is this an "I'd like gpsdate to work because it is there" issue? The ...


3

The command strace can be useful, you can limit the trace to only count -c or a subset of system calls, -e trace=set Trace only the specified set of system calls. The -c option is useful for determining which system calls might be useful to trace. For example, trace=open,close,read,write means to only trace those four ...


3

If you can get the pid, which shouldn't be hard with either ps, /proc/self or $! depending on whether or not you background it you can find this in: /proc/$pid/stat: utime %lu (14) Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by ...


3

With ntpdate: ntpdate -d 0.debian.pool.ntp.org Or for the offset only: ntpdate -d 0.debian.pool.ntp.org | sed -n '$s/.*offset //p'


3

For a running process you can do this: PID=5462 command ps -p "$PID" -o etime command ps -p "$PID" --no-headers -o etime As a general feature you can modify your shell prompt. This is my bash prompt definition: TERM_RED_START=$'\033[1m\033[31m' TERM_RED_END=$'\033(B\033[m' PS1='\nec:$(ec=$?; if [ 0 -eq $ec ]; then printf %-3d $ec; else echo -n ...


3

Access: 2014-05-20 11:04:27.012146373 -0700 Modify: 2014-04-05 20:59:32.000000000 -0700 Change: 2014-05-20 11:04:22.405479507 -0700 Access: last time the contents of the file were examined. Modify: Last time the contents of the file were changed. Change: Last time the file's inode was changed. The change time includes things like modifying the ...


3

There's no foolproof way to tell. However, for log files, the change time (as opposed to the modification time) which you see in the output of stat may be the time at which the compressed file was created, because the filesystem attributes of these compressed files are rarely modified after their creation. For .gz files which were not created by compressing ...


3

With zsh: mutt -s "Log" -a /path/to/*.log(.om[1]) example@example.com That uses zsh glob qualifiers. While other shell globs can only generate filenames based on their name, in zsh, you can use those qualifiers ((.om[1]) above), to select based on file attributes (type, size, times, permissions...) or other criteria of your own, affect the order, apply ...



Only top voted, non community-wiki answers of a minimum length are eligible