Hot answers tagged

20

You could use rsync (over ssh), which uses a single connection to transfer all the source files. rsync -avP cap_* user@host:dir If you don't have rsync (and why not!?) you can use tar with ssh like this, which avoids creating a temporary file: tar czf - cap_* | ssh user@host tar xvzfC - dir The rsync is to be preferred, all other things being equal, ...


12

It's the negotiation of the transfer that takes time. In general, operations on n files of b bytes each takes much, much longer than a single operation on a single file of n * b bytes. This is also true e.g. for disk I/O. If you look carefully you'll see that the transfer rate in this case is size_of_the_file/secs. To transfer files more efficiently, ...


9

date +%s%N will give the nano seconds since epoch To get the micro seconds just do an eval expr `date +%s%N` / 1000


9

It doesn't work because time is a shell keyword. There are external time binaries, but you don't appear to have one installed. This will likely work: nohup bash -c 'time sleep 2'


8

There's no much point asking for this kind of precision in a shell script, given that running any command (even the date command) will take at least a few hundreds of those microseconds. In particular, you can't really use the date command to time the execution of a command with this kind of precision. For that, best would be to use the time command or ...


7

By default, watch runs your command with /bin/sh -c '...' so the output you see is how /bin/sh interprets the time command. Your /bin/sh apparently doesn't have a builtin time. To run the command with a different shell, use the -x option to get rid of the default, then add your own explicit invocation of the shell whose builtin you want. watch -x bash -c ...


7

if the user is allowed to use at command, this is the perfect use for that: $ at 08:00 022116 at> myscript.sh at> <----------- ctrl-d here job 9 at 2016-02-21 08:00 if you get a message like "user blah is not able to run at", ask the syadmin to add this user to at.allow file or remove from at.deny file, depending on how it is used in your ...


6

You could use bc and printf: printf "%0.f" "$(bc <<<"$(date +"%s.%N")*1000")" This gives the number of miliseconds since january 1970. I didn't use the scale=n option of bc on purpose, because that would not round the value, instead it cuts the rest away (I know, it's pedantic). bc reads from file or from the standard input. <<< is a ...


6

The socket idea is the old venerable time protocol documented in RFC 868. The utility that synchronizes system time based on that protocol is called rdate. You're better off using NTP because NTP will track how the clocks of the two systems naturally drift apart over time and correct for it. The time protocol should be reserved for situations where NTP is ...


6

The accounting utilities (e.g. GNU's implementation) track user activity and provide a number of tools to report on it; for example, lastcomm will list the last commands executed, and sa (run as root) will provide an activity summary. To show the amount of time a given process ran, do something like sudo sa | grep chromium This will output a number ...


5

The structure of a pipeline doesn't allow time in the middle, only at the start of the pipeline. Also, time is a "shell keyword", as shown by type time. But nothing forbids the use of compound commands (and time each): time comm1 | ( time comm2 ) So, you could workaround using a sub-shell, like this: echo "12" | ( time python3 -c "a=input("");print(a)" ...


5

For -daystart the manual says: -- Option: -daystart Measure times from the beginning of today rather than from 24 hours ago. So, to list the regular files in your home directory that were modified yesterday, do find ~/ -daystart -type f -mtime 1 The '-daystart' option is unlike most other options in that it has an effect on ...


4

As you said date +%s returns the number of seconds since the epoch. So, date +%s%N returns the seconds and the current nanoseconds. Dividing date +%s%N the value by 1000 will give in microseconds.i.e echo $(($(date +%s%N)/1000))


4

For this answer, I'll assume that there may be several elements working hard to set your time straight. Since I don't really want to wild-guess about which one is working against you, I'll try and give you an answer which should help you find it yourself instead. On a UNIX system, the clock can typically be set using the stime system call. As things ...


4

@wurtel's comment is probably correct: there's a lot of overhead establishing each connection. If you can fix that you'll get faster transfers (and if you can't, just use @roaima's rsync workaround). I did an experiment transferring similar-sized files (head -c 417K /dev/urandom > foo.1 and made some copies of that file) to a host that takes a while to ...


3

I don't think you can pause system time. Lots of programs wouldn't like it anyway, because they generally expect time to go forward. If you paused the time, then any program going into sleep would never wake up. I don't understand exactly what you're trying to do, but I suspect that faketime would do what you're after. It lets you run programs with a fake ...


3

The simplest way is to use the --printf option as suggested by @don_crissti: stat --printf='%A %h %U %G %s %.16y %n\n' .bashrc If, for whatever reason, you can't do that you can parse the output of `stat -c '%y': $ stat -c'%A %h %U %G %s %y %n' .bashrc | awk '{$7=substr($7,1,8); $8=""}1;' -rw-r--r-- 1 terdon terdon 9737 2015-02-01 18:12:18 .bashrc Or ...


3

There is two types of time commands. One is shell built-in, belongs to bash. That's the one you see in your first example. Second one , is /usr/bin/time, that's the second one you saw. As for why it's different output, it's because you cannot pipe output to shell builtins. More on that here


3

Using last you can find this information. The following may be useful: last <username> | less It will return something like this: benlavery@Talantinc:bin $>last benlavery | less benlavery ttys005 Mon Aug 31 09:58 still logged in benlavery ttys005 fe80::105e:6b27:29ff:d967%en0 Mon Aug 31 09:14 - 09:36 (00:22) benlavery ...


3

When the network is configured via DHCP as it is here, that can set the timezone. See serverfault.com/questions/333348/ DHCP can also set the ntp server but you say that ntpd is not running so that wouldn't matter here. But as the solution indicates, ntpdate can also be run. So expanding upon my initial comment, you should make sure ntpdate is not around ...


3

The unix system is designed to run on UTC, timezones are a convenience for us mere humans who prefer to see a local time. Two users working on the one system, could sit in different timezones and therefore have different timezones set in their environment. It appears that you want to force the system to run in your timezone, but you also say that you want ...


2

Note: Although NTP had this idea of a nanokernel which could be used to patch OS's that don't use NTP, in Linux in particular is not in this case. The NTP code is in the kernel itself as you allude to in question 1. 0: How does this Nanokernel manage to deliver an accuracy less than the system clock tick (such as ns accuracy)? Accuracy greater than ...


2

Sample to try timerscript.sh: #!/bin/bash #timing in minutes with %m start=`date +%m` echo 'Start:' $start #do something e.g. wait for 1.30 minutes sleep 90 `end=`date +%m` echo 'End: '$end echo 'runtime: '$runtime


2

By definition, a.out is a child process of time. So time is the parent pid of a.out! here's a test where I replace a.out with sleep 60: $ time sleep 50 & timepid=$! $ aoutpid=$(pgrep -P $timepid) $ ps -o ppid,pid,start,cmd w -p $$,$timepid,$aoutpid PPID PID STARTED CMD 2065 2068 21:34:57 -bash 2068 3297 22:16:05 -bash 3297 3298 22:16:05 sleep 50 ...


2

If the time to start a shell is negligible compared to the time it takes to run the command, you can run an intermediate shell, and use the exec builtin to ensure that a.out replaces the shell rather than being executed as a subprocess. time sh -c 'echo $$; exec ./a.out'


2

To me, NTP is the obvious answer. Reliable and consistent - assuming some sort of Internet connection, with an option that's enabled on many distributions to set the clock directly during the boot-up process. However, this is an opinion-based answer, probably not suited to SE.


2

Bash's built-in time returns the exit status of the command. You can test that fairly easily with time false; afterwards, echo $? prints 1 as expected. You can also test something with a different exit code to confirm other codes are preserved: $ time bash -c 'exit 42'; echo "Exit code: $?" real 0m0.002s user 0m0.000s sys 0m0.000s Exit code: 42


2

Mac OS X doesn't ship with the GNU stack. You have "BSD Time" time.c,v 1.9. You can verify this by typing: strings /usr/bin/time | grep c,v BSD time doesn't support --verbose, but it does support /usr/bin/time -lp: $ /usr/bin/time -lp echo hi hi real 0.02 user 0.00 sys 0.00 700416 maximum resident set size 0 ...


2

ntpdate is giving you the "socket in use" error because you have a NTP daemon running. This is good. Now, the problem with VMs is that they tend to have a huge time offset (because of being frozen and restarted), and by default NTP panics and exit when the clock skew is too big. Add the following lines to /etc/ntp.conf: tinker panic 0 server ...


2

There's no standard definition for “fully start”. If you come up with a definition, there may or may not be a way to detect it. If your definition of “fully start” is “wait until the application becomes idle, waiting for user input”, then you can trace its system calls and look how long it takes to start reading user input. strace -o myapp.strace -tt myapp ...



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