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>