Date: Mon, 28 Jan 2013 17:38:58 +0100 From: Polytropon <freebsd@edvax.de> To: "Ralf Mardorf" <ralf.mardorf@rocketmail.com> Cc: FreeBSD quest <freebsd-questions@freebsd.org> Subject: Re: Usage of "restore" Message-ID: <20130128173858.a39a3305.freebsd@edvax.de> In-Reply-To: <op.wrmqo8k3uwjkcr@freebsd> References: <op.wrmmbb2cqhadp0@freebsd> <20130128165429.c5368afe.freebsd@edvax.de> <op.wrmqo8k3uwjkcr@freebsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jan 2013 17:28:10 +0100, Ralf Mardorf wrote: > On Mon, 28 Jan 2013 16:54:29 +0100, Polytropon <freebsd@edvax.de> wrote: > > The answer is in "man restore". :-) >=20 > No it isn't ;). I did read it. E=E1u c=F2ntrair! :-) -f file Write the backup to file; file may be a special device file li= ke /dev/sa0 (a tape drive), /dev/fd1 (a floppy disk drive), an or= di- nary file, or `-' (the standard output). Multiple file names = may be given as a single argument separated by commas. Each file will be used for one dump volume in the order listed; if the d= ump requires more volumes than the number of names given, the last file name will used for all remaining volumes after prompting = for media changes. If the name of the file is of the form ``host:file'', or ``user@host:file'', dump writes to the named file on the remote host using rmt(8). The default path name of the remote rmt(8) program is /etc/rmt; this can be overridden = by the environment variable RMT. You could even set $TAPE to the file name and omit -f. :-) > This was a Wald'n'B=E4ume situation. That's possible. > Even if I would have add a .bz2, I > would have missed it, since on Linux I .tar.bz backups and it's more > automated to extract a .tar.foo. But .tar.bz !=3D .dump and !=3D dump.bz (different programs: tar and dump are working differently). > However, I should add .bz2 in the future. At least this is a comfortable way to avoid confusion and know file content by simply looking at its name. > > Ern... two things: Do you _really_ have /bin/bash on FreeBSD? > > I know this is possible. > > > > And do you use any bash-specific features in your script? If > > not, why not use /bin/sh, the "universally" accepted standard? :-) >=20 > No /bin/bash, >=20 > # ls /usr/local/bin/bash > /usr/local/bin/bash >=20 > I run "bash file" instead of "sh file", IIRC I already had an issue when = =20 > writing a script and running "sh file". Okay, that is a fully valid solution, in that case #!/bin/bash is ignored. But just think about a "typical" worst case scenario: You have a script that requires bash, and you need to apply it it SUM with /usr unmounted, and you accidentally do not have a statically linked /bin/bash. Wouldn't it be much more convenient to rely on the /bin/sh default scripting shell? Maybe if you review your script, you can find out what bash-ism is employed and turn it into a valid sh equivalent while keeping the intended functionality. At a first glance, I don't see anything sh can't do. > I use it, since I use it on Linux too, another shell might cause issues, = =20 > if I continue writing this script or if I should write another script. =20 Interoperability for scripting is hard in regards of Linux, where sh isn't bash, and sometimes bash isn't bash either. :-) > I thought /bin/sh is a link to another shell. Sometimes it is. Sometimes not. -r-xr-xr-x 1 root wheel 115348 2011-08-21 20:23:20 /bin/sh* On FreeBSD, /bin/sh is technically ash ("This code is derived from software contributed to Berkeley by Kenneth Almquist.", see /usr/src/bin/sh/main.c), a replacement for the traditional Bourne shell whose name it inherits. It's a real binary, not a link. --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130128173858.a39a3305.freebsd>