After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?
For example, if there is a page http://www.domain1.com/page1.html
with a link to http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)
Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0. 24  4450 
sinister wrote: After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?
It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>
Your example is _not_ a valid URI.
--
Anne van Kesteren http://www.annevankesteren.nl/
"sinister" <si******@nospam.invalid> wrote: After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL.
Of course, it's a basic part of authoring almost any site.
Are there any pitfalls to this?
You need to change links if you move a file around within a site.
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)
That's true. But the browser may alter the file when it saves it in
order to prevent this. Browsers vary, and how you trigger this
behaviour may vary as well.
Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0.
Hmmm. Using the strange URL you quoted above? Not surprised that it
doesn't work, surprised that it actuallu crashes anything. But we are
talking IE here...
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"sinister" <si******@nospam.invalid> wrote in message
news:DR***************@nwrddc01.gnilink.net... After doing a websearch, it appears that it's OK to omit the "http:" to
form a relative URL. Are there any pitfalls to this?
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
This isn't relative. It shows no relationship of any kind to the first page,
which is on a different, unrelated web site. It is an absolute URL without
the "http:". Maybe some browsers assume a default protocol of "http:" if you
don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.
A relative URL is just that--identification of a page's location in
relationship to the location of the current page. If used on page1.html, a
URL of
page2.html
is a reference to a file called page2.html in the same directory as
page1.html. A reference to
../page3.html
points to a page in the first page's directory's parent directory. A
reference to
/page4.html
points to a page on the same server as the first page. These are all
relative.
"Anne van Kesteren" <ma**@annevankesteren.nl> wrote in message
news:bo**********@reader08.wxs.nl... sinister wrote: After doing a websearch, it appears that it's OK to omit the "http:" to
form a relative URL. Are there any pitfalls to this? It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>
Your example is _not_ a valid URI.
Which? There are 3 paths in my example.
--
Anne van Kesteren
http://www.annevankesteren.nl/
"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bo*************@ID-114100.news.uni-berlin.de...
"sinister" <si******@nospam.invalid> wrote in message
news:DR***************@nwrddc01.gnilink.net... After doing a websearch, it appears that it's OK to omit the "http:" to form a relative URL. Are there any pitfalls to this?
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
This isn't relative. It shows no relationship of any kind to the first
page, which is on a different, unrelated web site. It is an absolute URL
without the "http:". Maybe some browsers assume a default protocol of "http:" if
you don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.
A relative URL is just that--identification of a page's location in
relationship to the location of the current page. If used on page1.html, a
URL of
page2.html
is a reference to a file called page2.html in the same directory as
page1.html. A reference to
../page3.html
points to a page in the first page's directory's parent directory. A
reference to
/page4.html
points to a page on the same server as the first page. These are all
relative.
But http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces everything
from the hostname onwards."
It has this example: working from a base URL of http://WebReference.com/html/
the relative URL
//www.internet.com/
is translated into http://www.internet.com/
Similarly, http://www.w3.org/Addressing/rfc1808.txt has a base URL of
<URL:http://a/b/c/d;p?q#f>
plus a relative URL of
//g
being mapped to http://g
if I'm reading that doc correctly.
"Steve Pugh" <st***@pugh.net> wrote in message
news:39********************************@4ax.com... "sinister" <si******@nospam.invalid> wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to
forma relative URL.
Of course, it's a basic part of authoring almost any site.
Are there any pitfalls to this?
You need to change links if you move a file around within a site.
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
I think you misunderstood my example.
If the page
http://www.domain1.com/page1.html
contains
page2.html
or
/page2.html
those relative URLs become
http://www.domain1.com/page1.html
whereas I want "domain2.com", not "domain1.com".
About the strange example, with the leading "//":
http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces everything
from the hostname onwards."
It has this example: working from a base URL of
http://WebReference.com/html/
the relative URL
//www.internet.com/
is translated into
http://www.internet.com/
Similarly, http://www.w3.org/Addressing/rfc1808.txt has a base URL of
<URL:http://a/b/c/d;p?q#f>
plus a relative URL of
//g
being mapped to
http://g
if I'm reading that doc correctly.
What I'm wondering is if there are any drawbacks to this. (One that I
canthink of is that if someone saves the HTML page to their hard disk, the
linkwon't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)
That's true. But the browser may alter the file when it saves it in
order to prevent this. Browsers vary, and how you trigger this
behaviour may vary as well.
Right.
Also, I just tried it and it seems that clicking on the link after the
pagehas been saved to the hard drive crashes IE 6.0.
Hmmm. Using the strange URL you quoted above? Not surprised that it
doesn't work, surprised that it actuallu crashes anything. But we are
talking IE here...
Right...
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Anne van Kesteren wrote: sinister wrote:
After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?
It is not correct usage of the href attribute:
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.> It should
contain an URI: <http://www.w3.org/TR/REC-html40/types.html#type-uri>
Your example is _not_ a valid URI.
My understanding of RFC2396 is that //host and //host/path are
relative URIs, called network-path references (sec. 5). Appendix
C.1, titled "Normal Examples", shows how the relative URI //g
should be resolved when the base URI is http://a/b/c/d;p?q . The
resulting absolute URI is http://g . And that's not even an
abnormal example.
The HTML4.01 specification, section 6.4, says: "Relative URIs are
resolved to full URIs using a base URI. [RFC1808], section 3,
defines the normative algorithm for this process". But section 3
doesn't define any process of resolving relative URIs; section 3
talks about the various ways of establishing a base URL. And
indeed, HTML4.01, sec. 12.4.1, says that "user agents must
calculate the base URI for resolving relative URIs according to
[RFC1808], section 3". Does that mean there isn't a normative
algorithm for resolving URIs?
RFC1808, sec. 4, and RFC2396, sec. 5.2, on the other hand, suggest
possible algorithms for resolving relative URLs.
--
Jock
"sinister" <si******@nospam.invalid> wrote: "Steve Pugh" <st***@pugh.net> wrote: "sinister" <si******@nospam.invalid> wrote:
>After doing a websearch, it appears that it's OK to omit the "http:" to
>form a relative URL.
>For example, if there is a page
>http://www.domain1.com/page1.html
>with a link to
>http://www.domain2.com/page2.html
>you can abbreviate the second link as
>//www.domain2.com/page2.html
No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
I think you misunderstood my example.
Sorry, I missed the fact that they are two different domains.
And on reflection, once my memory started working I realised that yes,
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Calling it a relative URL is a bit misleading. Strictly speaking it is
a relative URL, but really the only thing it's relative to is the
protocol.
Which explains your problem with locally saved copies.
//example.com/foo/bar is then resolved as being
file://example.com/foo/bar and the browser goes off looking for a
local host called example.com.
Obviously it won't find it, but IE still shouldn't have crashed.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Wed, 5 Nov 2003, Steve Pugh wrote: a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
On Wed, 5 Nov 2003, Steve Pugh wrote: a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Alan J. Flavell <fl*****@ph.gla.ac.uk> wrote: Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
My reading of http://www.ietf.org/rfc/rfc2396.txt is that a relative URI
can omit only the scheme. Excerpted from Appendix C:
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
...
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
...
authority = server | reg_name
...
server = [ [ userinfo "@" ] hostport ]
Have I misread the RFC?
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"We are Microsoft. Resistance is futile. You will be assimilated."
"Steve Pugh" <st***@pugh.net> wrote in message
news:m9********************************@4ax.com... "sinister" <si******@nospam.invalid> wrote:"Steve Pugh" <st***@pugh.net> wrote: "sinister" <si******@nospam.invalid> wrote:
>After doing a websearch, it appears that it's OK to omit the "http:"
to >form a relative URL.
>For example, if there is a page
>http://www.domain1.com/page1.html
>with a link to
>http://www.domain2.com/page2.html
>you can abbreviate the second link as
>//www.domain2.com/page2.html
No, you'd shorten it to just page2.html or /page2.html
The version you give is very odd and might cause problems.
I think you misunderstood my example.
Sorry, I missed the fact that they are two different domains.
And on reflection, once my memory started working I realised that yes,
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Calling it a relative URL is a bit misleading. Strictly speaking it is
a relative URL, but really the only thing it's relative to is the
protocol.
Which explains your problem with locally saved copies.
//example.com/foo/bar is then resolved as being
file://example.com/foo/bar and the browser goes off looking for a
local host called example.com.
Right.
Obviously it won't find it, but IE still shouldn't have crashed.
Right, but...
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
As other people have said: RFC2396. Although, on a quick reread, I
can't see an explicit "SHOULD" for this case, I think it's a
reasonable opinion based on, amongst other things, the example //g
given in Appendix C.1.
Do you have a different opinion?
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Thu, 6 Nov 2003, Steve Pugh wrote: "Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
On Wed, 5 Nov 2003, Steve Pugh wrote:
a URL starting with // will resolve as //hostname/path and that should
work in any decent browser.
Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
As other people have said: RFC2396.
Sorry, you caught me out being lazy - I asked the question in
preference to actually consulting the spec.
Although, on a quick reread, I can't see an explicit "SHOULD" for
this case, I think it's a reasonable opinion based on, amongst other
things, the example //g given in Appendix C.1.
I can't fault you on that. The more formal part would be section 5,
and the specific paragraph seems to be:
A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.
The justification for wanting such references is given in the third
paragraph of section 5.
Do you have a different opinion?
I didn't really have an opinion at that point - I asked the question
because I was unsure - but I confess the right thing to do would have
been to consult the RFC - which I have now done - rather than to
pester usenet.
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
Totally agreed. I would certainly not recommend the use on a www site.
The benefits on that case (saving five bytes per off-site link) are
unlikely to outweigh the problems (broken local copies; uncertain
browser support).
On a site/network/whatever that was accessed via multiple schemes it
could conceivably be useful, but only in the case where the authority
and path would be the same for all usable schemes. Which in my
experience is rarely the case.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... On Thu, 6 Nov 2003, Steve Pugh wrote:
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
On Wed, 5 Nov 2003, Steve Pugh wrote:
> a URL starting with // will resolve as //hostname/path and that
should> work in any decent browser.
Do you have an interworking specification that says it SHOULD, or
is that merely your opinion?
As other people have said: RFC2396.
Sorry, you caught me out being lazy - I asked the question in
preference to actually consulting the spec.
Although, on a quick reread, I can't see an explicit "SHOULD" for
this case, I think it's a reasonable opinion based on, amongst other
things, the example //g given in Appendix C.1.
I can't fault you on that. The more formal part would be section 5,
and the specific paragraph seems to be:
A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.
The justification for wanting such references is given in the third
paragraph of section 5.
Do you have a different opinion?
I didn't really have an opinion at that point - I asked the question
because I was unsure - but I confess the right thing to do would have
been to consult the RFC - which I have now done - rather than to
pester usenet.
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
It works in IE 6.
What's the point of having a spec if the spec isn't followed?
"sinister" <si******@nospam.invalid> wrote: It works in IE 6.
And 'works' includes crashing, by you own account
What's the point of having a spec if the spec isn't followed?
Good question. Maybe Microsoft have an answer, considering how often
they fail to follow the spec...
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Alan J. Flavell" wrote: A relative reference beginning with two slash characters is termed a
network-path reference, as defined by <net_path> in Section 3.
Such references are rarely used.
The justification for wanting such references is given in the third
paragraph of section 5.
The example given in the justification is one that would be used infrequently,
however there is one good use for network-path references: Sites which are
accessible with http and https schemes can implement scheme independent links
to other servers, for example
<img src="//imageserver.example.org/example.gif" width="100" height="100"
alt="This is an example" />
Without network-paths, developers have a choice between using the http scheme,
which results in a warning message and/or broken image links when the page is
accessed over https, or using the https scheme which means unnecessary overhead
when the page is served over http (at least for static pages, for dynamic
content the server can set the scheme in references to other servers according
to the scheme used for accessing a page).
What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
This is widely implemented in current and older browsers such as Netscape 4
(and I believe even earlier versions of Netscape and Internet Explorer handled
this fine), as well as libraries such as the Perl HTTP library.
--
Klaus Johannes Rusch Kl********@atmedia.net http://www.atmedia.net/KlausRusch/
Alan J. Flavell wrote: What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
I've noticed slashdot.org uses it widely, which probably indicates browser
support is very good.
James
Alan J. Flavell wrote: What I still _don't_ know, is how well this interpretation is
implemented in the currently-used browsers. The RFC's comment "Such
references are rarely used" seems to be a bit of an alarm signal, no?
James Bursa <ja*********@strcprstskrzkrk.co.uk> wrote:
I've noticed slashdot.org uses it widely, which probably indicates browser
support is very good.
I wouldn't use that, or any other particular site to reinforce the
notion. To post a contrary example: We've all noticed many sites with
serious errors, therefore those errors can't be so serious (even if the
site doesn't work). :-\
--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
"sinister" <si******@nospam.invalid> wrote in message
news:6d***************@nwrddc01.gnilink.net...
But
http://www.webreference.com/html/tutorial2/3.html states:
"A relative URL that begins with // (two slashes) always replaces
everything from the hostname onwards."
First, just speaking logically: If webreference.com said a dog without a
tail is a cat, would it be right? "Relative" means "in relationship to". A
relative URL is one stated in terms that are relative to the location of the
current resource.
Now that I've said *that*, I see that the RFC defines "relative URL" as
anything that doesn't start with the protocol (what they are calling a
"scheme") and colon. So I concede that the technical term is defined this
way. I guess I can understand it if I think of the "scheme" as an uppermost
node on some hierarchy that includes all the resources (hosts, etc.)
underneath it. On a page requested via https:, a URL of "//a/b" is to be
interpreted "relatively" to this topmost "https" node--that is, the browser
should know that https://a/b is meant, not http://a/b.
"Harlan Messinger" <h.*********@comcast.net> wrote in message news:<bo*************@ID-114100.news.uni-berlin.de>... This isn't relative. It shows no relationship of any kind to the first page,
which is on a different, unrelated web site. It is an absolute URL without
the "http:". Maybe some browsers assume a default protocol of "http:" if you
don't use one. IE does if you leave out the protocol in the browser's
Address field; I don't know if IE will work properly if a URL like this is
in an HREF.
No, actually, it's a perfectly valid relative URI, where "relative"
means, in this case, that it's "relative" to the protocol used in the
base URI. Thus, if a site has a link to
"//domain2.example/page1.html", then if the base URI from which the
link is made is "http://domain1.example/page2.html", then the link URI
would resolve to "http://domain2.example/page1.html"; however, if the
base URI were in a different protocol, say
"https://domain1.example/page2.html" or
"ftp://domain1.example/page2.html", then the resolved link URI would
be "https://domain2.example/page1.html" or
"ftp://domain2.example/page1.html" respectively.
I actually had occasion to use such a link, years ago, on a page that
could be accessed with both a secure (https) or normal (http) Web
address, and which used images from a different domain which similarly
could be accessed by http or https; I wanted the images to be accessed
via the same protocol as the main page (since browsers typically give
warnings or refuse to display portions of the page if secure and
nonsecure protocols are mixed). The syntax starting with "//" worked
fine for my purpose, and on testing, proved to work in all common
browsers at the time (granted, this was in a time when Netscape 3.x
was still a common browser, so I don't know how well it works *now*.)
My discussion of absolute and relative URIs: http://webtips.dan.info/url.html
--
Dan
Sometime around Thu, 06 Nov 2003 12:41:27 GMT, sinister is reported to have
stated:
What's the point of having a spec if the spec isn't followed?
Take a look at how different all the browsers are. Then imagine how
different they would be if they were all completely making it up as they
went, rather than there being a specification for them to follow (albeit
somewhat badly).
--
Mark Parnell http://www.clarkecomputers.com.au
"sinister" <si******@nospam.invalid> wrote in message news:<DR***************@nwrddc01.gnilink.net>... After doing a websearch, it appears that it's OK to omit the "http:" to form
a relative URL. Are there any pitfalls to this?
For example, if there is a page
http://www.domain1.com/page1.html
with a link to
http://www.domain2.com/page2.html
you can abbreviate the second link as
//www.domain2.com/page2.html
What I'm wondering is if there are any drawbacks to this. (One that I can
think of is that if someone saves the HTML page to their hard disk, the link
won't work anymore since the URL is relative to the document as on the
website, not as on their harddrive.)
Also, I just tried it and it seems that clicking on the link after the page
has been saved to the hard drive crashes IE 6.0.
See the FAQ at Tim BL's personal page http://www.w3.org/People/Berners-Lee/FAQ.html#etc
I tested it a while ago. It failed in Lynx. I wouldn't be surprised if
it fails in other browsers too.
--
hzr
"Mark Parnell" <we*******@clarkecomputers.com.au> wrote in message
news:ql*****************************@40tude.net... Sometime around Thu, 06 Nov 2003 12:41:27 GMT, sinister is reported to
have stated:
What's the point of having a spec if the spec isn't followed?
Take a look at how different all the browsers are. Then imagine how
different they would be if they were all completely making it up as they
went, rather than there being a specification for them to follow (albeit
somewhat badly).
I agree. I didn't mean to say there's no point in having a spec, but rather
that the spec should be followed.
--
Mark Parnell
http://www.clarkecomputers.com.au This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ryan.fairchild |
last post by:
Ok I basically am creating a container for a bunch of other <div> tags.
But I want to make four jpegs/gif/whatever that goes in each corner so
they look rounded.
I thought this is how I would do...
|
by: Yeah |
last post by:
Is it absolutely necessary to include "http://" in an A HREF hyperlink?
Would it be wise to remove this from one's Links page, just to save code?
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
